Skip to content

Secure Login Service

Secure Login Service Release 5.19.0.4 2024-12-02

Various Improvements and Fixes

  • The OIDC OP no longer redirects to the redirect_uri in case of an unknown or missing client_id in the authentication request, in order to prevent attacks that would redirect via the trusted OP domain to an "evil" domain.

Secure Login Service Release 5.19.0.3 2024-09-27

Tomcat 10 Support

  • A new webapp has been added, "sls-webapp-complete-jakarta", which is ready to be deployed in a Tomcat 10 servlet container.

Secure Login Service Release 5.19.0.2 2024-09-11

Various Improvements and Fixes

  • Added support for using servlet container sessions when used without an HSP.
  • Fixed language selection not working when the browser blacklist feature was used, i.e. no language selection possible for the "UserAgent.jsp".

Secure Login Service Release 5.19.0.1 2024-06-24

Breaking Change

  • Removed support for the obsolete, proprietary ELCARD adapter authentication system. As of today, any installation using it should switch to either OpenID Connect or SAML.

Secure Login Service Release 5.19.0.0 2023-04-11

Breaking Change

  • Support for SHS ("Secure HandShake") has been removed completely, as this feature is not supported properly with TLS 1.3 and most current web browsers. Please check the SES 5.16 migration guide for information about how to update or replace existing login models that made use of this feature.

Various Improvements and Fixes

  • If http.ssl.accepted.cns is set to a list of CNs in the HTTP Adapter (or http.ssl.accepted.cns in the WS Adapter), previous behavior was to only check if the certificate CN is part of this list. Now the check is also OK if any of the SANs (Subject Alternate Names) is in the list of accepted CNs. (This reflects the fact that if http.ssl.enforce.host=true the hostname is allowed if it matches the cert CN or any of the cert SANs.)
  • Supporting non-http(s) URL schemes for do.redirect and do.logout in the case where the url.absolute.allow model parameter is set to true, e.g. URL myscheme99://somehost.net/...
  • Fixed rare concurrency issue in crypto.base32encode and crypto.base32decode script functions.
  • Fixed rare issue with setting a cookie in the response manually using the response.setHeader() function disabling the 'SLSPrefs' cookie.

Secure Login Service Release 5.18.0.0 2023-06-26

Geode distributed storage support

  • Support has been added to allow the SLS to read and store data to and from an Apache Geode store. As of now, the scripting functions with the new prefix geode. have to be used to perform the write and read operations. The connection to the Geode server is configured with a few new configuration properties. See "SLS Administration Guide", chapter "Geode", and "SLS Scripting Guide", prefix "geode", for details.

Groovy 4

  • Newer Groovy 4, replacing Groovy 2.4.x. All in all, Groovy 4 is backwards compatible, so normally this should not affect existing scripts, experimentally not even complex constructs of rather a kind that only programmers use.
  • There is no longer a groovy-all JAR, instead a selection of useful Groovy JARs is included with the SLS:
  • groovy (core Groovy functionality)
  • groovy-datetime
  • groovy-jmx
  • groovy-json
  • groovy-jsr223
  • groovy-macro
  • groovy-nio
  • groovy-sql
  • groovy-templates
  • groovy-xml
  • groovy-yaml

SAML IdP and SP adapters

  • Using the "future" key feature in the SP failed if encryption was used for assertions. The SP adapter now properly attempts decryption with both private keys.

Various Improvements and Fixes

  • With the introduction of JWKS support, the proxy handling in the OIDC RP had been broken. The configured proxy settings are now used for the backend calls again.
  • The compression of OIDC authorization code strings has been slightly reduced to address an issue with the compression algorithm which caused problems if attributes contained certain special characters.
  • Custom scopes configured in the OIDC RP were not picked up, and not set in the redirect authentication request.
  • The new model state show.json allows to directly send a JSON response to the client, instead of having to use a JSP with JSON content. See "SLS Administration Guide" for details about the new state.
  • Introduced new hard final timeout for SLS sessions. This timeout will be enforced regardless of the state of a session, even if it's currently being processed in a request. It can be configured with the new configuration property session.final.timeout.minutes (see "SLS Administration Guide" for details). If it is not configured at all, it will be enabled with a value of 60 minutes by default.
  • New script functions to simplify handling of incoming basic auth headers: function.getBasicAuthUsername(), function.getBasicAuthPassword() and session.setCredentialsFromBasicAuth(boolean failOnMissingCredentials), see "JEXL Guide" for more details.
  • Added a missing BouncyCastle depencency for the sls-shs-cli-client fat JAR (the tool is mostly used internally for testing interaction with HSP).

Removal of obsolete components

  • The ISAPI filter has officially been discontinued and will no longer be included in the SLS delivery.
  • Several obsolete ond/or outdated dependencies were removed.
  • The "codemirror" include which was only used by the scripting testing JSP ("JexlTest.jsp") but not by the actual SLS itself has been removed as well.

Secure Login Service Release 5.17.0.1 2022-12-19

Various Improvements and Fixes

  • Added code_challenge_methods_supported with value S256 to default OIDC OP Discovery Endpoint data returned by oidc_op.getConfig().

Secure Login Service Release 5.17.0.0 2022-12-02

Java 11 / Tomcat 9

  • Added official support for Java 11 and Tomcat 9. Note that thus far the SLS is still compiled with Java 8 to Java 8 bytecode and that Java 8 and Tomcat 8 + 8.5 are still fully supported. The SLS is now additionally tested and used with Java 11 / Tomcat 9 and thus these newer versions are now also officially supported.

OIDC OP+RP Adapters

  • OP+RP: Support for Proof Key for Code Exchange (PKCE, "Pixy"), with new settings oidc.rp.client.<no>.pixy.use, oidc.op.rp.<no>.pixy.require and oidc.op.rp.<no>.pixy.allowPlain, see "SLS Administration Guide" for details.
  • OP+RP: Support for Public Clients that send no resp. require no client_secret in the token request (typically used in combination with PKCE/"Pixy"), with two new settings oidc.rp.client.<no>.publicClient and oidc.op.rp.<no>.publicClient, see "SLS Administration Guide" for details.
  • OP: New script functions oidc_op.createConfigAsMap() and/or oidc_op.getConfig() allow to create, optionally change, and display OIDC OP metadata information for an OIDC discovery endpoint. See "SLS Administration Guide", chapter "OIDC OP Adapter", and also "JEXL Guide", prefix oidc_op, for details. There is also a new JSP included, OpConfig.jsp.
  • OP: New script functions oidc_op.createJwksAsMap() and/or oidc_op.getJwks() allow to create, optionally change, and display OIDC OP metadata information for an OIDC JWKS endpoint. See "SLS Administration Guide", chapter "OIDC OP Adapter" and also "JEXL Guide", prefix oidc_op, for details. There is also a new JSP included, OpJwks.jsp.

SAML IdP+SP Adapters

  • IdP+SP: Support for two new settings, idp.keystore.future.keypair.alias in the IdP and sp.keystore.future.keypair.alias in the SP, that allow to change key pairs / certificates much more independently on IdPs and SPs, in particular, changes are now possible without having to reconfigure and restart both an SP and an IdP at the same time. See sections "Replacing the IdP key pair and certificate" in the chapter about the IdP Adapter and "Replacing the SP key pair and certificate" in the chapter about the SP Adapter in the SLS Administration Guide for how to use the new settings.
  • IdP+SP: Allowing trusted SP resp. IdP Metadata with an EntityDescriptor that is marked as expired in XML (validUntil), as this caused issues in production. For example, already restarting the SLS could lead to an SLS that failed to initialize the corresponding SAML adapter. Note that since the SLS generally trusts credentials given in metadata (e.g. also the certificate within independently of certificate expiry), this is a more consistent approach (not excluding future consistent refinements).
  • IdP: Fixed a bug with handling an empty relayState parameter at login (failed to deserialize serialized SSO info which would affect further SP logins and SLO).
  • SP: Fixed NullPointerException for Response from IdP if login failed and Response contained a StatusCode without a sub StatusCode.

Bootstrap update

The "Bootstrap" CSS library used by the JSPs was updated to Bootstrap 5. As a consequence, JQuery is no longer included in new SLS deployments. Also, there have been a few breaking changes in Bootstrap 4 and 5, so customized JSPs might need to be slightly adapted if they are to be upgraded to the new Bootstrap version. Check the chapter "JSP" in the "SLS Administration Guide" for more information.

Various Improvements and Fixes

  • The performance log can now log times with higher resolution, with 3 or 6 decimal digits (e.g. instead of 12 now 12.456 or 12.456789) or with zero decimal digits as previously. The default is now 3 digits and can be changed by setting the new property log.performance.resolution=[millisecs|microsecs|nanosecs]. Note that how precise these times are depends on hardware and OS, but they usually help to analyze performance.
  • A bug was fixed in the handling of runtime exceptions generated with one of the JEXL functions function.failWith....(). This bug led to the handling of a request resulting in an HTTP 500 error instead of the model being switched to the default failed state.
  • Handling of URI fragment identifiers in a redirect URL has been implemented by adding the function session.setUriFragmentIdentifier(). It allows to specify a URI fragment identifier string which will be added to the final redirect URL.
  • New configuration property groovy.script.loginfo. If set to true, logs at level INFO for each Groovy expression the resulting class name (Script{MD5-hash-of-script-expression}) and script text at first compilation, as well as for each Groovy file the filename at first compiliation.
  • New tool "SlsFindGroovy" in the SLS delivery (see tools/findgroovy) that allows to heuristically search a given directory with SLS configuration files for a Groovy expression with a given MD5 hash. The new tool is normally not needed to operate an SLS, but there were occurrences of JVM crashes (i.e. bugs in the JVM, not the SLS!) which logged the generated Script<MD5> class name of a Groovy script expression and in this case the new tool can be helpful. The search is somewhat heuristic, but should typically find all Groovy expressions in files with indicated extensions.

Secure Login Service Release 5.16.0.3 2022-08-03

SES Identity (IDM) Adapter

  • Fixed a bug in 2 Syncope REST API calls that would fail when used in a password-less (sfa) login flow, due to the missing user credentials.

Secure Login Service Release 5.16.0.2 2022-05-06

Various Improvements and Fixes

  • Added missing OIDC related URI mappings to the "struts-config.xml" configuration file, as they are required when updating to the new SES 5.13 appliance release.
  • Re-added accidentally removed URI mappings for reset password model states and text resources for reset password JSPs.

Secure Login Service Release 5.16.0.1 2022-04-21

HTTP Adapter

  • Creates a variable response.contentBytes with the response body as a byte array, in addition to the already previously created variable response.content that contains the body bytes parsed as an UTF-8 encoded string. Useful for callouts that return binary data (e.g. QR Code PNG) or use other encodings.

Various Improvements and Fixes

  • Fixed JSON escaping of the log message for JSON-formatted logs (e.g. for logstash).
  • New script functions String function.getQRCode(String data) and String function.getQRCode(String data, int sizeInPixels) that yield a QR Code PNG for the given data string, base64-encoded, e.g. for easy inclusion in HTML pages like this: <img src="data:image/png;base64, <base64-data>"/>

Secure Login Service Release 5.16.0.0 2022-03-09

New IDM (SES Identity) Authentication Adapter

  • A new "IDM" adapter now allows to authenticate a user against a SES Identity backend, using basic authentication to verify the user's username and password credentials. See SLS Administration Guide, chapter "IDM Adapter" for details.

Webauthn Adapter IDM (SES Identity) Storage

  • The Webauthn adapter now allows to use the storage option idm to store the registered Webauthn credentials in a SES Identity database, using the new IDM adapter. See SLS Administration Guide, chapter "Webauthn Adapter", for details.

New OpenID Connect Relying Party (OIDC RP) Adapter

  • Supports the OpenID Connect Authorization Code Flow; see the corresponding chapter in the SLS Administration Guide for supported features and configuration/usage, as well as the JEXL Guide for documentation of the related new script functions.

SPNEGO Adapter (Kerberos)

  • Determining whether MS Kerberos login was with password or certificate ("Smartcard") has been refactored away from Sun/Oracle proprietary internal functionality. As a consequence the following ETypes are now supported for decrypting tickets in order to extract the above login information: Aes128CtsHmacSha1(17), Aes256CtsHmacSha1EType(18) and ArcFourHmac(23). No longer supported for that use case (but still for SPNEGO login itself) are the ETypes DesCbcCrc(1), DesCbcMd5(3) and Des3CbcHmacSha1Kd(16). As long as the JDK still allows access to the internas, it is still possible to use them as before with spnego.mslogin.ticket.decipher.useJdkInternalsIfAccessible=true, but please report back to USP if you needed to do that so that support for the needed ETypes could be considered for adding to future SLS versions. Note, however, that all three additional ETypes are officially deprecated for security reasons, as is ArcFourHmac(23), see RFC 6649 (2012) and RFC 8429 (2018).
  • Improved extraction of MS PAC data if several keytabs are configured; now all keys are tried, no longer just the first one of matching type.
  • Added two new script functions that can in some cases help analyze issues where SPNEGO Token verification with the JDK fails: spnego.traceSubject() and spnego.traceIncomingSpnegoToken(). See script guide for details.

OpenID Connect OP Adapter

  • Fixed a bug that basic auth passwords for client_secret in Token and Refresh requests which contained ":" were cut off there.
  • Fixed a bug that could lead to the SLS storing information about an authorization (role) multiple times in the login session.
  • Added new script functions for oidc_op.getOidcRequestWrapper(). The methods getBasicAuthUsername() and getBasicAuthPassword() get username/password from a basic auth header, if present. The method getRequestHeader(String name) gets the value of the indicated HTTP request header.
  • New script functions List<IRpInfo> oidc_op.getRpInfos() and IRpInfo oidc_op.getRpInfo(String clientId) that return objects for RPs with methods String getClientId(), String getClientSecret(), List<String> getRedirectUriList()and int getIndex(), also for access to configuration properties for the respective RP via index.
  • Removed the oidc_op credential provider, which no longer had any effect for four years (since SLS 5.5.0.0); credentials are since then created on-the-fly whenever needed for handling OIDC/OAuth messages.

LDAP Adapter

  • The new configuration property 'ldap.referral' allows to enable support for referrals in search results. Also, if referral support is not enabled (default) but a search result contains referrals, a warning will be logged, but no exception will be thrown, as was the case before. See "SLS Administration Guide", chapter "LDAP Adapter", for details.

HTTP and WS Adapters

  • Introduced a new config property http.tls.ciphers for defining TLS ciphers that are allowed to be used, similarly to the existing property http.tls.versions for allowed SSL/TLS protocols.

Removed Obsolete Adapters/Features

  • Removed the long obsolete SAML "SAP" 1.1 IdP and Responder Servlet.
  • Removed the SuisseID Adapter (last certificates issued by SuisseID expired in Dec 2021).

Secure Login Service Release 5.15.0.8 2022-01-20

Various Improvements and Fixes

  • Fixed a bug in the PKI adapter where extraction of CRL URIs from certificates as used for CRL checks using the CachedURICRL CRL plugin would fail for all certificates, i.e. CRLs checks were not possible (bug since SLS 5.15.0.0).
  • Fixed a bug in the simple failover mechanism which would result in the failover working only once, e.g. switching to the second backend when the first one went offline, but then not switching back when the first one came back online, and the second one went offline.
  • Fixed a bug in the adapter initialization which was introduced with the new Webauthn adapter. It could, under certain circumstances, lead to errors when a JSP was invoked which required certain functionality from a specific adapter before any actions using that adapter had been invoked before (e.g. the SP or IdP selection page in an SP or IdP).

Secure Login Service Release 5.15.0.7 2021-12-20

Log4j 1.2.17_p1 patch

  • The Log4j 1.2.17 library used by the SLS has been patched and a few classes were removed that were responsible for some known vulnerabilities. However, none of these vulnerabilities affected SLS instances in any SES setups, as they relied on Log4j functionality not used by the SLS. Still, just to address any lingering doubts, these classes were removed. The vulnerabilities addressed by the patch are:
  • CVE-2021-4104
  • CVE-2020-9488
  • CVE-2019-17571

Secure Login Service Release 5.15.0.6 2021-11-23

LDAP Adapter

  • Fixed a bug in the attribute update functionality, where the names of configured attributes were not evaluated with JEXL/Groovy anymore, only as fixed value. The bug was introduced in 5.15.0.5 through the WebAuthn LDAP storage extension.

Secure Login Service Release 5.15.0.5 2021-11-02

LDAP Adapter

  • The LDAP adapter now better supports group searches, by creating the new JEXL variable ldap.search.dns with a string array holding all DNs that were found in a filter search. This helps to search for groups that are not directly assigned to a user, but inherited through other groups.

SAML IdP Adapter

  • New method int getIndex() for the ISpInfo instances returned by idp.getSpInfos() and idp.getSpInfo(String aliasOrEntityId), for access to configuration properties for the respective SP via index.

SAML SP Adapter

  • New method int getIndex() for the IIdpInfo instances returned by sp.getIdpInfos() and sp.getIdpInfo(String aliasOrEntityId), for access to configuration properties for the respective IdP via index.

Various Improvements and Fixes

  • Fixed a bug in the slowdown mechanism which could lead to a model state being skipped by using POST requests during the slowdown waiting time. This bug was introduced by another fix (of a potential infinite loop during slowdown) which was done in SLS 5.13.0.0 (SES 5.10.0.0).
  • Failures of Groovy scripts at runtime now log the involved scripts with line numbers from the stacktrace in the error log message text.
  • Added a new script function function.getVariableNames() that returns a sorted list of the names of all script variables, Groovy shortcut is getVarNames().
  • Client for sending mails updated so that now supports TLSv1.2 (updated javax.mail client from 1.4.2 to 1.6.2).

Secure Login Service Release 5.15.0.3 2021-09-17

WebAuthn / FIDO2 Adapter

  • Fix in language resources.

Secure Login Service Release 5.15.0.2 2021-09-17

WebAuthn / FIDO2 Adapter

  • Shows more info about the credential friendly name at registration.

Secure Login Service Release 5.15.0.1 2021-09-16

WebAuthn / FIDO2 Adapter

  • Changed default for property webauthn.reg.authenticatorSelection.authenticatorAttachment from cross-platform to any attachment (not generating in publicKey Javascript).
  • Added WebAuthn credential provider to sls-system.properties.
  • Small fixes in language resources and SLS Administration Guide.

Secure Login Service Release 5.15.0.0 2021-08-25

New WebAuthn / FIDO2 Adapter

  • The new WebAuthn Adapter supports using FIDO2 compliant tokens such as USB tokens or built-in fingerprint readers for stronger authentication, or password-less login. The new adapter allows persisting registered credentials in LDAP or (for testing purposes) in memory. See the chapter "WebAuthn Adapter" in the "SLS Administration Guide" for more information.

Dynamic activation of DEBUG / TRACE logging

  • Two new script functions session.activateDebugLog(boolean activate) and session.activateTraceLog(boolean activate) that allow to activate or deactivate DEBUG resp. TRACE logging for the current login session. This can be very helpful for analysis of issues in production where generally activating DEBUG resp. TRACE logging is often not possible without risks.

HTTP / Webservice Adapters

  • Reduced the number of requests sent to backends by the backend monitor, based on the target URL. If multiple backends have the same URL, or the same monitoring check URL, only one actual request will be sent to that URL during a monitoring run. So, if there are 10 HTTP backends with different URLs, but all use the same .connectionCheckUrl value, only 1 instead of 10 requests will be sent to the backend by the monitor.

Various Improvements and Fixes

  • Added filtering of the password credential value from all log levels, including debug and trace. Requires the new configuration property log.filter.creds.secrets to be set to true.
  • More specific error messages if creating or sending a mail message failed, with full stacktrace in exception log; plus more detailed trace/debug logs.

Secure Login Service Release 5.14.0.1 2021-04-13

SAML IdP and SP Adapters

  • Both IdP and SP Adapter now support multiple certificates for signature verification in trusted SP resp. IdP Metadata: First all certificates with usage "signing" are tried, then all certificates with undefined usage. This allows, for example, to better support use cases where an IdP provides two certificates during a transition time of a few weeks, as does Microsoft.
  • Selection criteria for certificates for encryption resp. signature verification are now documented in the SLS Administration Guide in the chapters about these two adapters.

LDAP Adapter

  • Fixed a bug where for custom LDAP create actions a URL configured with ldap.myalias.create.url was not used, instead fallback to ldap.url. Same fix for ldap.myalias.add.url and ldap.myalias.remove.url.

Secure Login Service Release 5.14.0.0 2021-03-11

TLSv1.3

  • Basic support for TLSv1.3, requires Java 8u261 or later.
  • HTTP Adapter: Experimentally it is necessary to set the system property jdk.tls.client.protocols at startup of the JVM to a string that includes TLSv1.3 and as usual to set the SLS config property http.tls.versions to a string that also includes TLSv1.3. Note that SSLv3 (or older) is no longer supported in the HTTP adapter.
  • Other callouts from the SLS should in principle automatically use TLSv1.3 when the above system property has been set and the server on the other side agrees.
  • SLS front: Requires Tomcat 8.5; no extra settings are necessary, optionally e.g. accepted protocols can be limited in server.xml in the Connector tag in the sslEnabledProtocols attribute.

Improved Mobile ID Support

  • The SLS delivery now contains full configuration examples for the model, HTTP adapter configuration, request-/response-templates and scripting for implementing a Mobile ID login flow with the Swisscom REST API. See the "SLS Administration Guide", chapter "Mobile ID", for details.

Groovy Script Files Auto Recompilation

  • Before this release, if Groovy script files in one of the configured Groovy script directories changed, the Groovy scripts were recompiled automatically. This behavior has now been turned off by default.
  • It can be turned back on by setting groovy.scriptdirs.autorecompile=true, but note that this is not guaranteed to work perfectly in all situations, especially under high load there can be race conditions.
  • In productive environments, it is generally recommended to have this feature turned off to prevent accidental changes. However, if scripts are protected from accidental modification, having the feature active could sometimes allow to implement and deploy workarounds without having to restart the SLS.
  • The feature is certainly useful for integration/testing, as it allows to make and test almost all changes to Groovy scripts without an SLS restart.
  • If activated, now an INFO log entry GROOVY_SCRIPTDIRS_RECOMPILE_SUCCESS is written when auto recompilation was successful, and an ERROR log entry GROOVY_SCRIPTDIRS_RECOMPILE_FAILURE is written if it failed. Note that if recompilation fails, the last good state continues to be used.

OpenID Connect / OAuth 2.0 Adapter

  • Fixed a bug in naming: The authorization code was misnamed "token code" almost throughout the code and documentation. This has been fixed. As part of that all script functions with prefix oidc_op_tokencode have been deprecated and are now all available with the new prefix oidc_op_authorization_code. Similarly, the SLS config property oidc.op.tokencode.validity.secs has been deprecated; oidc.op.authorization_code.validity.secs should be used instead.
  • Better support for handling claims in id_token, refresh_token and userinfo resp. attributes in the authorization code that are not simply strings: The oidc_op_authorization_code methods now allow to set/get any object type as value, no longer restricted to strings; the oidc_op_id_token, oidc_op_refresh_token and oidc_op_userinfo methods were already generic. So, you can, for example, set an array or list of strings and after parsing the authorization code or JWT then get it back as a list of strings. For convenience, methods List<String> getAttributeAsStringList(String name) and List<String> getClaimAsStringList(String name) have been added which automatically convert list items to strings and return an empty list instead of null if there is no claim/attribute.

HTTP/Webservice Adapter

  • The HTTP Adapter can now automatically process JSON and XML responses via templates: Just define a template named template.file.http-response-<alias> and make sure the file extension of the template is either .xml or .json, then HTTP responses with a content-type header that contains xml or json will be processed automatically and variables generated accordingly.
  • The HTTP Adapter now supports automatic execution of actions after a successful callout, similar to the WS Adapter; define actions with configuration properties http.<alias>.action.<no>.
  • It is now possible to configure separate timeout values for each custom HTTP / WS call using the property [http|ws].<alias>.connection.timeout, which will override the default timeout setting for the given call.

SAML IdP and SP Adapters

  • Fixed a bug where two trusted SPs resp. trusted IdPs could be configured with metadata that contains the same EntityID. Previously only configuration of one of these two trusted SPs resp. trusted IdPs would have been used for both.

Google Authenticator Adapter

  • Non-numeric characters in the verification code are now ignored, since many apps display it with hyphens (999-999) or spaces (999 999) in between, which users sometimes include in their submission.

SLS Seal (DataProtector Replacement)

  • Internally a new API is used for DataProtector functionality, but it is still able to use legacy DataProtector keystores.
  • It comes with a new command line tool that allows to still encipher and decipher based on legacy DataProtector keystores, but is also able to create a new kind of keystores and keys (e.g. uses AES instead of 3DES).

Various Improvements and Fixes

  • Message resource property files are now processed with UTF-8 encoding (Java by default reads message bundle files as ISO-8859-1 encoded). This allows to use UTF-8 characters directly in the property files, given that they are edited with a UTF-8 aware editor. This behavior can be disabled with the new configuration property resources.encoding.legacy.
  • The new model trigger alwaysIf is similar to the if trigger, but is evaluated on every request, and allows to re-start or switch to a different model even if one is already in the session. This can be useful for things like restarting a SAML login flow on the IDP if the user did not complete a login attempt, but then start another one on a different SP.
  • The model state do.redirect now automatically sets a flag in the session which ensures that the next incoming GET request will forward the model to the next state after do.redirect, which is something very likely to happen in certain social-login flows. In previous releases, the SLS would just have repeated the same direct state again. The old behavior can still be triggered using the new model state parameter goto.next.state.
  • New script function session.resetLoginSlowdown() to reset a login slowdown.
  • The model state do.logout now also properly supports absolute URLs that were configured in redirect.logout. In addition, the model state now allows to specify the redirect URL with the new state parameter url.
  • When a challenge is created with the create.challenge state, but then the flow is aborted by a reset of the model (i.e. by sending a request with a cmd parameter), the challenge will automatically be removed from the session. This prevents an issue with the do.success state where previously in such situations the login might have failed to to an existing, but not validated challenge.
  • New script functions for base64URL en-/decoding, as needed commonly around JWTs and OAuth / OpenID Connect, hex en-/decoding, as well as more script functions for base64 and base32 en-/decoding, all with crypto function prefix.
  • New script functions function.bytesToString() and function.stringToBytes() to convert more conveniently between byte arrays and strings, using UTF-8 or a chosen char to/from bytes encoding (charset).
  • Updated the Apache HttpClient library to 4.5.13.
  • Updated Groovy library to 2.4.21.
  • Removed the IAIK crypto library.

Secure Login Service Release 5.13.0.1 2020-09-29

OpenID Connect Adapter Security Fix

  • When the redirect_uri parameter in an OIDC AuthnRequest was invalid, the SLS still responded with a 302 back to that URI, which (in case of someone tampering with that parameter) creates a security risk ("open redirect"). This has been fixed so that the SLS will now respond with a 400 Bad Request HTTP status code and a JSON error response containing the proprietary error code "redirect_uri_mismatch" that e.g. Google uses, plus more detailed description.

Secure Login Service Release 5.13.0.0 2020-08-31

SAML Security Enhancements

  • Migration SP Adapter: Note that the new configuration properties sp.idp.<no>.sso.idpinit.allow and sp.idp.<no>.sso.idpinit.inresponseto.allow which have both default values false (i.e. stricter behavior than previously) may have to be set to true in some cases, the former setting if IdP-initiated login is needed, and both most prominently if logins at the IdP regularly take so long that the login session at the SP is already expired when the response arrives. More details below and also in the "SLS Administration Guide" in the chapter "SP Adapter" in a new section "Security Concerns, esp. IdP-Initiated Login".
  • SP Adapter: A new setting sp.idp.<no>.sso.idpinit.allow that allows to prohibit IdP-initiated logins, as they are intrinsically harder to be secured, as the SP did not ask for login and there is thus no "challenge" to correlate with. The default is false.
  • SP Adapter: By default now rejects Responses during IdP-initiated login where either the Response contains an InResponseTo XML attribute or its assertion contains an InResponseTo in the SubjectConfirmation of the Assertion. This check can be deactivated by setting sp.idp.<no>.sso.idpinit.inresponseto.allow to true. Use case for allowing is SP-initiated logins at the IdP that take so long that the login session at the SP expires and thus the response from the IdP arrives as a new login session. However, it is generally recommended to instead increase the lifetime of the login session in these cases.
  • SP Adapter: If the Assertion contains an InResponseTo in the SubjectConfirmation and there was an AuthnRequest (i.e. SP-initiated login), the comparison with the ID XML attribute of the AuthnRequest is always done; login fails if they do not match.
  • SP Adapter: Now remembers previously successfully presented Assertions during their lifetime and blocks all attempts to reuse the same Assertion. This is important especially for IdP-initiated logins, where the SP cannot compare e.g. the InResponseTo in the Assertion to the ID in its original AuthnRequest, since there has been no AuthnRequest. (Note that this mechanism only provides partial protection in cases where there are several SP instances behind a load balancer.)
  • SP and IdP Adapters: Mandate that SAML requests and responses contain all mandatory XML attributes. Requests and responses must contain ID, Version and IssueDate. In addition responses to a request that contain an InResponseTo attribute must match the ID of the request.

General SAML Improvements and Fixes

  • In the SAML IdP Adapter setting parameters for a custom SAML Response (e.g. mainStatusCode)only had the desired effect if done for do.saml.idp.sendemsg but not if done for do.saml.idp.createmsg.

Various Improvements and Fixes

  • The SLS now logs a new warning SLS_LDAPS_REQUIREDwhen trying to connect to an LDAP server that mandates LDAPS (TLS/SSL) but plain LDAP is configured.
  • Fixed wrong netmask calculation in script functions function.isIpInNetwork(), function.isIpInAnyNetwork() and function.isClientIpTrusted; e.g. 1.2.3.4/24 was interpreted as the much larger network 1.2.3.4/8.
  • The IP-related script functions function.isIpInNetwork(), function.isIpInAnyNetwork() and function.isClientIpTrusted now transparently support IPv6 and IPv4 addresses. Also supported are IPv4 IPs wrapped into IPv6 (in "compat", "6to4" and "terero" formats). See the JEXL Functions Guide for the respective functions for more details.
  • No longer evaluating other model triggers if the model is triggered with cmd parameter. Previously this could lead to exceptions in the exception log because script model triggers were evaluated before e.g. script variables for headers were set.
  • Two new script functions function.urlEncode(String input, String charset) and function.urlDecode(String input, String charset) that allow to explicitly specify the charset to use, instead of implicitly UTF-8 in the already existing functions with just one parameter.
  • Propagation of headers to applications via HSP and generally of session attributes to the HSP now provides more control over encoding. In essence the value can be provided in already encoded form via a script expression like ${function.urlEncode(session.getCred('username'), 'ISO-8859-1')} and in addition by indicating that the provided value is already encoded so that the SLS does not attempt to encode it itself. New properties are app.header.<name>.isValueEncoded=<boolean>, app.header.<name>.encoding=<encoding> and session-attribute.valueProvidedEncoded.<no>=<boolean>; new script functions are response.propagateHeaderToApp(String name, String value, boolean valueAlreadyEncoded, String encoding) and response.propagateHeaderToApp(String name, String value, String path, boolean valueAlreadyEncoded, String encoding). For more information see the respective sections in the SLS Admininstration Guide for the new properties and the JEXL Functions Guide for the new functions.

Secure Login Service Release 5.12.0.5 2020-07-06

HTTP/WS Adapter

  • If the HTTP/WS backends were very slow, but the configured monitoring URLs responded fast, and backend monitoring was enabled, it was possible that the SLS ran into an endless failover loop caused by timeouts. This has been fixed in that now backend will be tried more than once within one request.

Secure Login Service Release 5.12.0.4 2020-06-05

HTTP/WS Adapter

  • Fixed selection of private key with configured alias in keystore (property <adapter-type>.<action-alias>.key.alias).

Secure Login Service Release 5.12.0.3 2020-05-26

HTTP/WS Adapter

  • The connection pooling in the HTTP/WS adapter did not work if SSL/TLS with mutual authentication was used. This has been fixed, so that there will be much fewer connections created by the adapters in such scenarios.
  • If dynamic debug/trace logging is enabled on a session, the HTTP adapter will now log more low-level I/O data.

Secure Login Service Release 5.12.0.2 2020-05-18

Security Enhancements

  • The HTTP and WS Adapters used to accept self-signed certificates if a dedicated truststore was defined via the system property javax.net.ssl.trustStore. This has been fixed. To ease migration of productive installations, it is possible to restore the previous behavior by setting a new SLS configuration property http.dedicated.ssl.trustStore.allowSelfSigned=true resp. ws.dedicated.ssl.trustStore.allowSelfSigned=true. If it is set and a dedicated truststore is defined, the SLS logs a warning at startup. Note that even though the new property may come in handy in test environments, it is generally recommended to simply add self-signed certificates to the dedicated truststore instead of using the new configuration property. Note also that the issue did not affect installations that do not define a dedicated truststore and thus use the truststore of the JVM.

Secure Login Service Release 5.12.0.1 2020-04-08

NTLM Adapter

  • Support for NTLMv1 has been dropped. This protocol, originally created in 1987, is by now severely broken in terms of security.

Secure Login Service Release 5.12.0.0 2019-12-19

Secure Handshake (SHS)

  • Now supports Secure Handshake (SHS) with TLS 1.3, provided the HSP supports it (HSP 4.21.0.0 or later). Supported TLS SignatureSchemes with TLS 1.3 are: rsa_pss_rsae_sha256 (0x0804), rsa_pss_pss_sha256 (0x0809), rsa_pss_rsae_sha384 (0x0805), rsa_pss_pss_sha384 (0x080a), rsa_pss_rsae_sha512 (0x0806), rsa_pss_pss_sha512 (0x080b).
  • SHS with TLS 1.2 now also supports the above TLS SignatureSchemes and continues to support legacy RSA PKCS#1 and DSA signatures with a number of hash functions.
  • SHS wit TLS 1.0 and 1.1 continue to support legacy RSA PKCS#1 and DSA signatures with fixed hash type (concatenated MD5 and SHA1 hashes).
  • SHS with SSLv3 is no longer supported (SSLv3 is generally not supported any more by HSP 4.21.0.0 and later).
  • Extended documentation of SHS in the "SLS Administration Guide" in the chapter about "PKI Adapter".

Secure Login Service Release 5.11.0.0 2019-09-27

Groovy / JEXL Improvements

  • Added a new script function saml.createOpenSamlObject(String className) which can usually just be given the simple name of the desired class like "Assertion". In the exceptional case where you may need to construct a SAML object that is not in the "core" package, you can indicate a fully qualified class name with package in the form "x.y.z.SomeOpenSamlObject". The existing function saml.createOpenSamlObject(Class clazz) has been deprecated and it is recommended to switch to the new function, whenever possible with simple class names without package. The goal is to make configurations more forward compatible with eventual upgrades of OpenSAML.
  • Added two new scripts functions saml.toMultiLineString(samlObject) and saml.toSingleLineString(samlObject) that return XML string representations of SAML objects like e.g. a SAML Assertion.

Various Improvements and Fixes

  • Fix: Added the missing JEXL/Groovy prefix saml to internal properties.
  • The script functions jwt.validateSignatureNotExpired() no longer fail if the given signed JWT lacks the optional "kid" header parameter.
  • Fixed an issue in the backend monitoring for LDAP backends; could use wrong credentials if used an alias that contains hyphens (-).

Secure Login Service Release 5.10.0.4 2019-11-29

NTLM Adapter

  • The error handling has been adapted to mark an AD backend as unavailable when a session key negotiation fails, in order to enforce a failover in such a situation.

Secure Login Service Release 5.10.0.3 2019-10-25

HTTP/WS Adapters

  • HTTP/WS adapter initialization optimized: Most initializations are now only done once per SLS startup instead of once per login session. This is helps most if there are lots of different callouts, like e.g. if there are a lot of different WS adapter SOAP backend call methods.
  • Internal optimizations in the HTTP and WS adapters that can help improve performance (detection of stale and idle connections in a dedicated thread, less temporary objects created on the heap per callout).

Groovy / JEXL Improvements

  • Fixed a bug in the JEXL function function.getSlsErrorId() which caused the function to not return the error ID if it was used in a JSP while the self- redirect after POST was enabled.

Various Improvements and Fixes

  • Fix: Added the missing JEXL/Groovy prefix saml to internal properties.
  • The script functions jwt.validateSignatureNotExpired() no longer fail if the given signed JWT lacks the optional "kid" header parameter.
  • Fixed an issue in the backend monitoring for LDAP backends; could use wrong credentials if used an alias that contains hyphens (-).

Secure Login Service Release 5.10.1.2 2019-09-20

  • The performance logging has been adjusted by disabling it completely for the backend monitoring log. The reason is that the recent change (adding the request URIs to the log) made especially the log lines for the monitor very long, as it checks all backends at once. But also, the performance measurement really is not relevant for the backend monitoring.

Secure Login Service Release 5.10.0.2 2019-09-16

HTTP Adapter Fixes

  • The global proxy settings were not recognized correctly and no proxy was used if none was configured for the specific HTTP call. This has been fixed so that the global default proxy settings are used correctly again.
  • The connection check which uses the URL configured by the property "connectionCheckUrl" did not properly use corresponding proxy settings if a proxy had been configured for the HTTP call.

Various Fixes

  • Some custom-set cookies were sometimes set two or more times in the response by the SLS.
  • Fixed an internal server error that could happen if a regular "show.jsp" was used to display a JSP in which then certain headers were set manually that would usually be set by the "do.success" state.
  • Fixed an issue in response.setHttpStatusCode() where setting the status had no effect if done in a JSP.
  • Vastly extended the session lock timeouts, and also fixed handling of session stickyness during failover if there is no session anymore, to avoid a situation with a possible infinite loop behavior.

Secure Login Service Release 5.10.1.1 2019-09-11

  • Added more detailed and narrow performance measurement to the HTTP/WS adapter call-out.

Secure Login Service Release 5.10.0.1 2019-06-04

Various Improvements and Fixes

  • Fixed a bug in deserialization of SAML SSO attributes defined with idp.sso.attr.<no>.*: empty values lead to failing to serialize all SSO attributes and passing them empty at a second SSO login at the SAML IdP.
  • Fixed a race condition in loading of message resources that could occur in some rare situations, most likely during SLS startup.

Secure Login Service Release 5.10.0.0 2019-04-18

Security Fixes

  • Signatures of the refresh_token in Refresh Requests to the OIDC OP were not correctly validated, so that a refresh_token signed with a wrong RSA private key could be accepted and yield correctly signed id_token, access_token and (depending on configuration) an updated refresh_token. A similar bug affected also the two jwt.validateSignatureNotExpired() JEXL/Groovy script functions.

Challenge / Response Improvements

  • The challenge generator in the SLS (used in the model state create.challenge) has been revamped to always use the full range of values for each digit in numeric challenges (previously, it never generated challenges that would start with "0", thus limiting the range of possible values).
  • Two new optional configuration properties, challenge.length and challenge.characters allow to further tailor the challenges that are created. Please see "SLS Administration Guide", chapter "Challenge / Response" for details.

JEXL/Groovy Functions

  • New IDP functions idp.createAssertion() and idp.sealAssertion() allow to create SAML assertions also in non-SAML related flows, without using any IDP-related model states. See "SLS Administration Guide", chapter "SAML IdP Adapter", section "Assertion creation by state or scripted" for details.
  • New function function.updateVarsFromXml() allows to dynamically create and update variables based on XML data, such as an XML response body from an HTTP adapter call. It requires to define a regular SLS text template which contains the XML structure of the expected response, and definitions for the variables to create (type and name), placed within the corresponding XML nodes. This simplifies processing XML responses and eliminates the need for manual XPath processing of an XML response body in many cases. Please see "SLS Administration Guide", chapter "Updating variables from XML data with templates".
  • New function function.updateVarsFromJson() allows to dynamically create and update variables based on JSON data, such as a JSON response body from an HTTP adapter call. It requires to define a regular SLS text template which contains the JSON structure of the expected response, and definitions for the variables to create (type and name), placed within the corresponding JSON nodes. This simplifies processing JSON responses and eliminates the need for manual JsonPath processing of a JSON response body in many cases. Please see "SLS Administration Guide", chapter "Updating variables from JSON data with templates".
  • The set of script functions function.failWithAuthenticationError() now also has a variant with zero message arguments, for messages without any arguments. Also, providing more message arguments than allowed, no longer results in an ArrayIndexOutOfBoundsException (but still results in an error).
  • Fixed a potential concurrency issue in the jwt.validateSignatureNotExpired() JEXL/Groovy function that affects only the variant with keystore parameters.

JEXL/Groovy Variables

  • New variables that facilitate access to properties of the incoming HTTP request, like request.uri and request.method. Please see "SLS Administration Guide", chapter "JEXL Expressions", section "Request Variables" for a detailed description of all the new request-related variables.

Various Improvements and Fixes

  • The SLS Log4j logging appender has now new configuration parameters which allow to better deal with multiline stacktrace logging. They allow to disable multiline logging, so a stacktrace is concatenated into one single line.
  • The SLS Log4j logging appender now also allows to apply escaping of special characters in the log message, in order to better support JSON or XML formatted log output. See "SLS Administration Guide", chapter "Logging" for details.
  • Fixed a bug in the processing of proxy configuration properties for the HTTP and Webservice adapter. Due to the bug, a proxy setting was not properly processed if the grouping alias in the property name contained a dot ("."). This made use of proxies for SOAP adapter calls on the SES appliance impossible due to the aliases generated by the GUI.
  • Fixed a bug in the SLS language cookie creation which caused the SLS language cookie to have an invalid max-age attribute, and as a result be stored on the client side as a session-bound cookie. This bug had been introduced recently in SLS 5.8.0.0 when support for version 0 cookies was removed.
  • The HTTP and WS adapters have a new optional configuration property, (http.<alias>.key.alias / ws.<alias>.key.alias) which allows to specify the alias of the entry in the SLS keystore of the key that should be used in an SSL connection with mutual authentication. Please see the "SLS Administration Guide", chapter "HTTP Adapter" / "HTTPS / SSL/TLS" for details.
  • The WS adapter now has two new optional configuration properties which allow to enable logging of the entire request and response body in case a technical SOAP error was detected in the response (the response body is logged on level ERROR). The property which enabled this logging is ws.soap.fault.log and must be set to true, while the other new property ws.soap.fault.log.filter allows to define a comma-separated list of values that should be filtered out (hidden) from the log (please see "SLS Administration Guide", "Fault Response Logging" for details.
  • New Security Check for Challenge/Response: If a challenge/response had been started with the create.challenge action, but at do.success no verified challenge credential is present now login fails by default, for security reason. The correct way of handling this situation in the login model would be to discard a cancelled challenge/response using the new JEXL/Groovy script function session.cancelChallengeResponse(). For migration it is recommended to first set the SLS configuration property sls.challenge.verification.mandatory to false, then to observe the system for WARN log entries of this kind: [SYSTEM] [SLS_WARNING] Reason: 'Challenge/Response initiated, but no verified CHALLENGE credential.'. Whenever such warnings occur, adapt the login model such that they no longer appear and once all such warnings are gone, remove the property again.
  • Fixed two bugs in the password policy. The first bug was that the setting checkCount only behaved as expected if set to 2 or higher. If set to 1, it behaved as if not set or set to 0, i.e. all checks had to pass. The second bug was that a regex defined with regularExpression was not checked if checkCount was considered (i.e. set to 2 or higher, due to the first bug) and checkInclusionPattern was set to true, even though the regex has precedence in this case. Documentation of password policy settings and procedure has been extended in the "SLS Administration Guide".
  • The "SLS Administration Guide" now documents the criteria for when a backend is considered available for failover and load balancing. See the chapters about the respective adapters (HTTP, WS, LDAP, RADIUS, NTLM) or search for the text "criterion for backend availability".
  • The trace log now logs response status and headers (if the ContainerSessionFilter is activated, which it usually is, including currently on the SES Appliance). This comes close to sniffing HTTP output of the SLS and works independently of whether the SLS is accessed with TLS/SSL or not.
  • The do.oidc.op.handlemsg action in the case of OAuth when validating a received access_token in an Authorization Bearer header now automatically sets the HSP credential final timeout header for the corresponding access area level ("member"/"customer") after successful access_token validation.
  • The new configuration property sls.response.buffer.size allows to set the size of the response buffer of the HTTP response. Increasing the buffer size from the container default can help in cases a response from the SLS is incomplete (i.e. some response headers are missing) because the buffer is too small. This can be an issue with certain Tomcat 8 versions where the size of this buffer is not configurable. Also, adjusting the buffer size allows to adjust memory usage in such situation.
  • With Tomcat 8.5 and newer, the content type of CSS files included in the SLS response was accidentally changed to "text/html", due to a bug in the SLS container session filter. This led some browsers to not interpret the contents as CSS anymore. This has been fixed so that the SLS works correctly with Tomcat 8.5 and newer as well.
  • The model state "do.trxinit*" has been modified to not enforce a certain SES session state anymore.

Secure Login Service Release 5.9.0.1 2019-01-19

  • Fixed an issue with the release build of the SLS web application and RPM, which caused the Servlet API jar file "servlet-api-2.4.jar" to be included in the SLS "WEB-INF/lib" directory. This could cause problems at runtime depending on the behavior of the servlet container classloader, so an upgrade is necessary to avoid this.
  • Fixed an internal misconfiguration for the JEXL/Groovy function prefix jwt that could under some circumstances result in failure to use jwt functions.

Secure Login Service Release 5.9.0.0 2019-11-30

  • The HSP (WAF) and SLS now support dynamically setting / overriding the HSP session timeout values with the SLS. So a virtual host could have a certain default for the final timeout, like 1 hour, and the SLS could change it to 2 hours for certain users (strong authentication, certain authorization etc.). Please note that the HSP will still restrict the values set by the SLS to the limits defined in the HSP configuration (see "HTTP Secure Proxy Administration Guide" for details). In the SLS, there are two ways to do this: Either through the existing static configuration properties for SES Session Attributes (see chapter "SES Session Attributes" in "SLS Administration Guide"), or through new JEXL function response.setWafSessionTimeout() (2 variants available; see "SLS JEXL Guide" for details).

OAuth 2.0 Support

  • The OpenID Connect OpenId Provider (OIDC OP) adapter now also provides some generic OAuth 2.0 support, for the same flows as supported by the OIDC OP, i.e. for the Authorization Code Flow, as well as for Refresh requests. (UserInfo requests are not part of OAuth 2.0.) See the corresponding chapter in the "SLS Administration Guide" for more details.

Various Improvements and Fixes

  • The new optional configuration property "xpath.ignore.empty.nodes" allows to make the WS (Webservice) adapter ignore XML response nodes with empty values when creating JEXL / Groovy variables, so that a SOAP response with a certain node will not override an already existing variable with an empty value (by default, if the node exists, the value will be updated with its value, even if the node is empty).

  • Fixed a bug in the evaluation of JEXL/Groovy script model triggers: If the script expression threw an exception, its cause was not logged and further script model triggers were not evaluated at all. (Note that the order in which script triggers are processed is not defined, their conditions must be mutually exclusive). In the now fixed code, whenever a script model throws an exception, the exception is logged and the result of script evaluation is considered false, so that further script model triggers are still processed afterwards, and generally request processing in the SLS proceeds. In addition, the SLS now logs a warning if more than one script trigger evaluated to true, as behavior is undefined in that case (no natural order of login models).

  • When using the HTTP adapter with the "do.auth" model state, and an alias property that refers to a set of custom HTTP properties, these custom properties MUST contain a property with the list of the required credentials, because the state "do.auth" needs to be able to mark these credentials as verified after the HTTP call. But in the previous release, this property was not mandatory, and if it was missing, the credentials would simply not be marked as verified, which would then lead to an error in the "do.success" state. This has now been fixed, and the SLS will immediately fail the authentication with a corresponding error.

  • Fixed a bug that when values were stored using session.setUserInfoValue() in the User-Info cookie, the key for the value was treated case-insensitive, so that keys that only differ by case were only stored once (which one was undefined). This also applied to the "USERNAME" item that is automatically stored with the value of the USERNAME credential if e.g. explicitly setting in addition a value with key "username".

Secure Login Service Release 5.8.0.0 2018-10-25

Servlet API

  • Upgraded the SLS servlet API dependency to 3.0.1. As a consequence, a servlet container with support for this version of the API is mandatory; in case of Apache Tomcat, this means that Tomcat 7 is the oldest supported version. Furthermore, thanks to this update, all cookies created by the SLS now set the optional flag "HttpOnly".

HTTP Adapter

  • The HTTP adapter has been improved in that the internal functionality executed during a "do.auth" model state is the same as during a "do.http" state, just with a different alias, and some minor differences in terms of defaults. As a consequence, an actual authentication step can now just as well be performed with a "do.http" state. All that is needed is to set the property ".credentials" for the custom HTTP call; while this was possible already in the old releases, it only checked if the listed credentials existed, but did not mark them as verified after a successful call. Now it does, just as it always did during "do.auth". There were also other small inconsistencies between "do.auth*" and "do.http" in terms of configuration handling (e.g. it was not possible to freely define a POST body in a "do.auth" call). With this update, the handling of all request-, backend- and proxy settings behave exactly the same in all cases.
  • Request timeout settings were not correctly processed at startup, which caused the HTTP (and Webservice) adapters to always use the default timeout of 60 seconds.

SAML

  • Removed the long obsolete OIOSAML SAML 2.0 SP (superseded by the SLS SP Adapter). Note that the SLS may now log a warning if the related `samlsp' credential provider is still configured in SLS properties or the OIOSAML SP servlet in the SLS web.xml; all OIOSAML SP related settings can be safely removed from configuration.

Performance Log

  • The performance log now logs minimal information about incoming HTTP requests and outgoing HTTP responses, which can be very helpful during integration and and may be vitally useful for analysis of incidents in production. For requests, HTTP method and URL without query string plus parameter names (but not values) are logged very early in request processing. For responses, HTTP status code plus, if present, Location, SLSStatus and AccessArea headers are logged very late in request processing. For the Location header only the URL without query string plus query parameter names (but not values) are logged. The format of the request information in the new log entries is JSON (max. compressed); thus it might be extended with additional fields in the future (possibly configurable at runtime), which could allow to "zoom in" into specific areas of the operating SLS. NOTE: The existing log records have not been changed at this time, so the file as a whole is not all JSON formatted. Note that the performance log does not log ping requests (cmd=pingsls).

JEXL/Groovy Functions

  • Setting script variables to null using function.setVariable() or the Groovy shortcut setVar() did so far not allow to set variables to null. As a workaround, it was possible to set variables with simple names directly with var myvar = null (JEXL) or myvar = null (Groovy). It is now allowed to set variables to null with the usual functions. Accordingly, the semantics of function.hasNonEmptyVariable() and hasNonEmptyVar() have been extended to cover also the case where a variable exists and is null. In this case these functions now return false. (In the past they returned true in this case, but this could only happen if a variable had been set to null directly using one of the workarounds.)

  • Three new scripting functions simplify dealing with (IPv4) IPs and networks: function.isIpInNetwork(String ip, String network), function.isIpInAnyNetwork(String ip, List<String> networks), and function.isClientIpTrusted(List<String> trustedNetworks).

  • Three new scripting functions allow to easily generate secure random challenge strings: function.generateChallenge(), function.generateChallenge(int len), function.generateChallenge(int len, String chars). See the JEXL guide for more details.

  • Under some circumstances, the script function googleauth.createQRcode() would not render a QR code, but either trigger an exception, or just result in an empty string (depending on the JEXL configuration settings). This was fixed so that the function now works correctly in that situation.

  • When variables are persisted in the SLS user-infoo cookie, using the property "persist.variables", they are - by default - restored at the beginning of every incoming request, if there is no such non-empty variable already. This may cause problems in flows with multiple JSPs where at some point a persisted variable is to be removed during the flow in JEXL or Groovy, but then gets restored with its original value from the cookie after the next JSP gets posted. The behavior for restoring persistent variables can now be changed to once per session with the new optional configuration property "persist.mode" (see "SLS Administration Guide" for details). NOTE: On the SES appliance, the property is set to "session" by default.

  • Fixed NullPointerExeception when trying to set a script variable to null if trace log is activated.

Various Improvements and Fixes

  • Properties for tenants do not have to be numbered anymore, nor to have a continuous numbering in the property name, e.g. tenant.1, tenant.2 etc. The problem with the old implementation was that a missing number in between (e.g. tenant.1, tenant.3, tenant.4 ...) resulted in all the tenants after the numbering gap being ignored. This has now been fixed, so it does not matter anymore if the numbering has gaps, or if numbers are used at all.

  • The SLS will not create any cookies with the "version" attribute anymore. In other words, version 1 cookies are not supported anymore. The configuration property for setting the version for custom success cookies is not used anymore. Besides being a very obsolete cookie attribute, it is now also not supported by the most current HSP releases anymore, so cookies with the version attribute might not even work anymore (but experience shows that they are barely used by anyone today).

  • The model state "do.success" now allows to specify the list of credential types required for a successful login as a state parameter (or property). If this is set, it overrides the static model property ".credentials". This allows, for instance, to have a static default in the global model property and a dynamic override right at the final model state. Also, the global model property ".credentials" supports dynamic expressions now, e.g. model.login.credentials=#{Util.getRequiredCredentials()}.

  • A new model state "do.success.jsp" has been introduced, which is basically a merge of the "do.success" with the "show.jsp" state. It allows to show any given JSP after a successful login, instead of performing a redirect. Just like "do.success", this new state sets all the required response headers to signal a successful authentication to the reverse proxy, set session attributes etc. The state parameter ".param.jsp" allows to define the JSP to display, while the parameter ".param.invalidate" allows to define if the SLS session should be terminated at this point or not. If the JSP needs to access information from the login session such as JEXL/Groovy variables or credentials, the session must be kept alive until the JSP has been displayed (it is still possible to invalidate the session from within the footer of the JSP). Like "do.success", this new state also supports defining the list of required credentials.

  • The error message displayed when a password policy check failed due to the new password being too short or too long was invalid and confusing, potentially also mixing up english text parts with another language.

  • Passwort Policy no longer required: The behavior of the model state "do.changepassword" has been adapted so that it will no longer trigger an error if there was no local password policy loaded at a previous point in the model. In such a case, it will only perform basic checks like comparing the two new passwords given. This change eliminates the need for having the state "get.passwordpolicy" in the model whenever a password change operation should be done with the LDAP adapter.

  • An issue was fixed with the multi-tenancy feature, where a tenant that had been deliberately selected in a request through the URL parameter was then overwritten in a subsequent request, due to the request URI path. Now, the tenant will not be resolved anymore if there is one in the session already, except if explicitely set with either the URL parameter, or by scripting function.

  • The self-redirect after a POST request didn't work as expected if the POST request forwarded the model to a "show.jsp" state (only if the target state was a state like "get.cred"). This has been fixed, so that the self-redirect now also works correctly with "show.jsp".

Secure Login Service Release 5.7.0.0 2018-03-19

HTTP- / LDAP-Adapter

  • For both the HTTP and the LDAP adapter it is now possible to select the backend used in a "do.auth*"-state by setting an additional ".property"-value for the state, just as with the "do.ldap" and "do.http" states. This allows to configure multiple backends (or groups of backends) under different aliases, each with its own failover- or load-balancing settings, and then select the appropriate one for authentication at runtime. See "SLS Administration Guide", chapter "Model" (documentation about state "do.auth") for details.

RSA SecurID Adapter

  • In cases where the RSA SecurID adapter received either a NEW_PIN_REQUIRED or NEXT_TOKENCODE_REQUIRED response, the SLS handled this like a failed login attempt and performed a login slowdown, if that feature was enabled. This has been changed so that these responses will not trigger a slowdown anymore.

Groovy

  • The new Groovy function hasNonEmptyVar() is a replacement for the old JEXL function function.hasNonEmptyVariable().

  • A new section has been added to the "Groovy" chapter of the "SLS Administration Guide" which contains a table listing all "old" JEXL functions and their corresponding, shorter Groovy inline function (e.g. var() instead of function.getVariable()).

OpenID Connect

  • Now enciphering the access_token and potentially sensitive parts of the refresh_token.
  • Documented the format of tokens generated by the OP in the "SLS Administration Guide" and added a note that clarifies that the term "token code" always refers to the authorization code of the OpenID Connect "Authorization Code Flow".

Various Improvements and Fixes

  • The feature which automatically persists scripting variables in the user info cookie restored these variables in every following request, accidentally overwriting the value of already existing session variables. This has been fixed so that variables are only restored from the user info cookie, if they don't already exist with a non-empty value.

Secure Login Service Release 5.6.0.3 2017-12-29

SAML

  • New global property saml.securityConfiguration.signatureReferenceDigestMethod that allows to define the Reference Digest Algorithm in XML signatures. The default value im SAML XML signatures has also changed from the nowadays cryptographically weak value http://www.w3.org/2000/09/xmldsig#sha1 to http://www.w3.org/2001/04/xmlenc#sha256. See the SLS Administration Guide in the new chapter "SAML Global Settings" for more details.
  • Fixed null pointer exception if SAML key store alias does not correspond to a key pair in the key store when signing a SAML message for sending.

HTTP Adapter

  • The HTTP adapter now also supports the methods PUT, PATCH and DELETE in addition to GET and POST, in order to properly support invocation of REST interfaces.

Various Improvements and Fixes

  • The model state parameter for referencing the grouping alias for a "do.ldap" or "do.http" state has been changed to "param.alias" from both "param.searchalias" ("do.ldap") and "param.groupalias" ("do.http"), respectively. However, the old values are still supported, as is the simple ".property" syntax.
  • When a resource bundle in a custom bundle directory was tenant-specific, but not for a specific locale, it was ignored in the resolution process.
  • When a custom LDAP operation backend URL property value with multiple URLs (for failover), it was not properly evaluated and a runtime exception occurred. This has been fixed. However, it is still not recommended to define the backend URLs with scripts, since this approach does not work well with the SLS backend monitoring and various failover and load-balancing mechanisms.

Secure Login Service Release 5.6.0.2 2017-11-03

  • Added fallback to configured default language in the resource bundle resolution mechanism. So if a key only exists in language-specific resource bundles, but not any default (non-language) bundles, the SLS will attempt to specifically resolve it with the bundle of the configured default language, if it was not found for whatever language the session currently has.

Secure Login Service Release 5.6.0.1 2017-10-31

  • Fixed problem with custom resource bundles, where a key that existed only in the default bundle (without a specific locale) was not found at all, if there was also a locale- specific bundle. The SLS would perform the lookup only in the matching locale-specific bundle in that case.

Secure Login Service Release 5.6.0.0 2017-10-03

Various Improvements and Fixes

  • Added support for adding the model name to prefixes of state-specific message resource keys. This allows to adapt the message with the same key differently, for the same state, in each model. The model name must be prefixed to the state name using an underscore separator, e.g. "[login_get.cred]some.key=...". See chapter "State-Specific Error Messages" in the "SLS Administration Guide" for details.

Secure Login Service Release 5.5.0.0 2017-09-12

JSON Web Tokens

  • There is a new chapter about JSON Web Tokens (JWTs) in the SLS Administration Guide that describes available functionality for handling JWTs in the SLS.
  • New configuration properties that allow to easily create JWTs (main use case is propagation of identities to backends, similar to SES Tickets), see the see the SLS Administration Guide for configuration and use.

OpenID Connect

  • No longer creating OIDC credentials. They only existed for technical reasons to preserve OIDC messages from the orignal HTTP request to where they were needed in the do.oidc.op.handlemsg model action. This is now done without creating an OIDC credential. Settings that configure an OIDC credential are now silently ignored and can be removed, a credential is never created. Script functions oidc_op.hasOidcRequest() and oidc_op.getOidcRequestWrapper() still work in the same way, independently of whether they are called before or after the do.oidc.op.handlemsg model action.

SAML

  • New script functions in the SAML IdP and SP, idp.isMessageAuthnRequest(), idp.isMessageLogoutResponse(), sp.isMessageResponseAssertion() and sp.isMessageLogoutRequest(), that allow to tell different incoming messages more easily apart in cases where the same login location serves multiple purposes.

Various Improvements and Fixes

  • The properties which define additional custom directories for configuration files (custom.properties.path) can now be in any properties file inside the SLS "WEB-INF" directory; they don't have to be in the `"sls.properties" file anymore.
  • A bug has been fixed in the handling of a "req" parameter that was wrapped into the "requestedPage" parameter, and prevented proper handling of a T5-initiated re-authentication flow.

Secure Login Service Release 5.4.0.1 2017-08-28

JEXL/Groovy Functions

  • There is a new scripting function session.setObject() which corresponds to the existing session.getObject(). It allows to set any kind of Java object in the SLS session.

Various Improvements and Fixes

  • Using scripting expressions in an LDAP custom operation URL did not work; the expressions were not resolved at runtime. This has been fixed so that a property like ldap.userlookup.search.url=${pre_defined_url} is now supported.
  • There was a case sensitivity issue in the LDAP adapter when using custom operations, and selecting the backend with the JEXL function "ldap.putLdapBackendSystem()." If the alias parameter in the function was not lower-cased, the backend system was not mached correctly.
  • Fixed a bug in the decryption of transaction data in a "req" parameter.

Secure Login Service Release 5.4.0.0 2017-07-26

Configuration Overrides

  • It is now possible to create files with the suffix ".overrides" in addition to the properties files. Any properties set in such files will override the values defined in a ".properties" file. This can be used to have common defaults in the properties files, and then override them in additional files, for example for test environments etc. See "SLS Administration Guide", chapter "Configuration" for details.

SAML SP and IdP

  • Multitenancy support now allows to select the tenant automatically based on the alias of the sender of the current SAML message. So in an Identity Provider, each registered Service Provider could be configured as a tenant, based on the alias of the SP in the configuration. This would allow to customize the JSPs, screen messages etc. based on the SP alias without any scripting magic. Please see "SLS Administration Guide", chapter "Multitenancy support" for details.
  • Configurable signature algorithms and block ciphers and new, stronger defaults. The default signature algorithm for signed SAML messages (and the SAML Assertion) is now http://www.w3.org/2001/04/xmldsig-more#rsa-sha256, i.e. no longer using the now weak and deprecated SHA1 but SHA256 by default. The default blockcipher is now http://www.w3.org/2001/04/xmlenc#aes256-cbc, i.e. now using AES256 instead of AES128 by default. Both signature algoritms and block cipher can be configured in the SP and IdP adapter, either for all trusted IdPs resp. SPs or per specific IdP resp. SP. See SP and IdP adapter chapters in the "SLS Administration Guide" for details.
  • Note that the deprecated OIOSAML SP does not support signatures with SHA256 in case of a signed LogoutRequest with Redirect Binding; use SHA1 there, e.g. idp.sp.<alias>.message.sigalg=http://www.w3.org/2000/09/xmldsig#rsa-sha1.
  • Signatures with SHA256, SHA384 and SHA512 are now also supported for Redirect Binding (previously only for XML signatures, i.e. POST Binding).
  • The SAML IdP and SP adapters now support the "<xi:include" tag in metadata XML files, which can be used to separate parts of the files (like the Base64 certificate data) from the rest of the XML structure.

JEXL/Groovy Functions

  • There is a new JEXL function prefix crypto. which provides several functions for encrypting and decrypting data, based on pre-configured settings. This allows to encrypt any value, either with a key from a keystore, or one from a passphrase, with configurable cipher algorithms, keystore types etc. Please see the "SLS JEXL Guide", prefix crypto., and the "SLS Administration Guide", chapter "Custom Encryption Functions".
  • The crypto. prefix also contains several other security- / crypto-related functions for hashing, generating random numbers or strings etc.
  • New JEXL function function.clearVariables(String prefix) allows to delete all variables whose name match the given prefix. This allows to, for example, remove all "ldap.*" variables holding values from a previous lookup (in the same login session) before performing a new LDAP call, in cases where the lingering variables from the first LDAP operation could be a problem. See "SLS JEXL Guide" for details.
  • Deprecation information has been added to the JEXL guide document. All functions that are marked as deprecated have a corresponding tag, and some information about which function to use instead.

Various Improvements and Fixes

  • The protocol support in the HTTP adapter was set to TSLv1 by default; that has been changed to TLSv1.2.
  • Added a few missing language resource keys related to Google Authenticator JSPs for Spanish, Italian and French.

Secure Login Service Release 5.3.0.1 2017-07-11

  • Fixed an LDAP adapter issue with the JEXL function ldap.putLdapBackendSystem() where the wrong backend would be used IF the function was used to set the backend for a custom operation which did NOT have any URL configured.

Secure Login Service Release 5.3.0.0 2017-07-07

User Filter

  • The previously removed "User Filter" feature was added again, with small implementation changes and an additional new JEXL function function.isUserAllowedByFilter() which allows to trigger the filter at any point in the model.

Custom configuration subdirectories

  • It is now possible to add custom subdirectories to the SLS WEB-INF directory, and put property files in there. This feature can be used to group property configuration files as desired. See "SLS Administration Guide", chapter 3 "Configuration" for details about the new configuration property custom.config.path.

Custom Message Resource Directories

  • It is now possible to configure additional subdirectories which can contain message resource property files, which will automatically override those in the "classes" directory. That way, it is possible for instance to have tenant-specific message resources in separate tenant-specific directories. See "SLS Administration Guide", chapter "Localization", configuration property custom.resources.path, for details about this feature.

Various Improvements and Fixes

  • It is no longer necessary to define function prefixes like function in Groovy script classes with constructs like def function = var('function'). (Note that to access other variables from the JEXL/Groovy context within Groovy script classes, it is still necessary to use e.g. var('myVariable'). Note also that all of this does not apply to Groovy expressions or to Groovy scripts called with runscript.groovy(...); there variables are still directly available by their names.) There is also now a shorter way to set variables with a period ('.') in their name, setVar('myVariable', 'myValue').
  • The JSP tags getJexl, doJexl, ifJexl and whileJexl have been deprecated. Instead, new corresponding tags with a more generic name where added: getScript, doScript, ifScript and whileScript. This makes more sense since these tags can not only contain JEXL expressions, but also Groovy. The old tags will of course still be supported.

Secure Login Service Release 5.2.0.3 2017-MM-DD

  • Fixed a problem with the handling of the backend status, which in some situations lead to "BACKEND_UNAVAILABLE" errors after a backend had once gone offline, but then come back online later. The problem was specifically related to the LDAP adapter.
  • Fixed an issue with the backend monitor for LDAP backends where the wrong principal could be used for checking the connection, more precisely there could be a fallback to using the default principal when a more specific one was declared.

Secure Login Service Release 5.2.0.2 2017-06-20

  • Fixed an issue with very long BACKEND_UNAVAILABLE log messages. This happened in the HTTP adapter, where this log message did not log the URL from the "..connectionCheckUrl" property, but the one from the "...url" property.

Secure Login Service Release 5.2.0.1 2017-05-16

  • Some changes in the SLS RPM package for the managed platform (the version was removed from the package name, and the Tomcat dependency was changed from Tomcat 6 to Tomcat 8.

  • Fixed another issue with self-redirect related to the "FailedAction" (basically the handling of a "failedState" in the model).

Secure Login Service Release 5.2.0.0 2017-05-05

OpenID Connect (OIDC) 1.0 OpenID Provider (OP) Adapter

  • New adapter that implements an OpenID Connect (OIDC) 1.0 OpenID Provider (OP). OpenID Connect 1.0 is an authentication protocol based on the OAuth 2.0 framework for authorization protocols. A major use case for OpenID Connect is mobile Apps. The SLS supports OpenID Connect 1.0 Authorization Code Flow, UserInfo and Refresh Requests. Note that the new adapter is roughly the OIDC equivalent of a SAML 2.0 Identity Provider (IdP) for SAML 2.0, and configuration in the SLS is also very similar and provides similar flexibility and versability. For details about the new adapter see the "SLS Administration Guide".
  • New JEXL/Groovy functions for the OIDC OP (prefix oidc_op) and for general handling of JSON Web Tokens (JWTs) (prefix jwt); see the SLS JEXL Guide for details.

HTTP / WS Adapter

  • Improved the HTTP / Webservice adapter proxy support in that it is now possible to define separate proxy settings for each custom HTTP / WS call (in addition to the global proxy settings). Also, the HTTP and WS adapter now allow to configure the allowed TLS versions for the backend connections with the new configuration property http.tls.versions (in order to be able to enforce TSLv1.2, for example). There are also new configuration properties for tuning connection handling, http.connection.total.max, http.connection.perRoute.max and http.connection.keepAlive.default. See "SLS Administration Guide", "HTTP Adapter" and "Webservice Adapter" for details.

Various Improvements and Fixes

  • Updated the Apache httpclient library in the HTTP / Webservice adapter in order to address an issue with SNI (Server Name Indication) support in a TLS handshake.
  • Fixed a NullPointerException in the PKI adapter that could occur if using the adapter with incorrect configuration.
  • Monitoring of backends of the RADIUS adapter now allows to optionally specify username and password, as well as arbitrary attributes, to use for checking the availability of the RADIUS backends, with new configuration properties radius.monitor.username, radius.monitor.password and radius.monitor.request.attr.<no>. See "SLS Administration Guide", "RADIUS Adapter" for details.
  • The self-redirect in response to a POST request used the URI of the current model for the location header. But in some rare cases, this caused problems, for instance when the model in question wouldn't even have a URI. This issue was fixed by instead using the same request URI of the POST request for the subsequent GET request.

Secure Login Service Release 5.1.0.3 2017-03-22

  • Monitoring of backends of the RADIUS adapter now allows to optionally specify username and password, as well as arbitrary attributes, to use for checking the availability of the RADIUS backends, with new configuration properties radius.monitor.username, radius.monitor.password and radius.monitor.request.attr.<no>. See "SLS Administration Guide", "RADIUS Adapter" for details.

Secure Login Service Release 5.1.0.2 2017-01-24

  • Fixed a new bug in failover mechanism, introduced with the new failover and load-balancing functionality. That bug would lead to the SLS not testing the connection to a backend once it was offline and came back online later, under certain circumstances; either a restart of the SLS, or enabling the backend monitoring was required. This has been fixed, so an upgraded SLS not using the new failover or load-balancing functionality still works as before.

Secure Login Service Release 5.1.0.1 2016-12-15

  • Fixed minor bug in audit logging introduced by custom log variable changes in release 5.1.0.0.

Secure Login Service Release 5.1.0.0 2016-12-14

Potential Update Issue(s)

  • Credential Providers overriding each other: A fix in the SLS credential provider configuration handling has been implemented, which can lead to some SLS instances not starting up anymore after an update due to their invalid configuration. A small configuration change is required in such a case.
  • Scripting Engine streamlined: JEXL 2 is now in strict mode by default, make sure you set it explicitly back to lenient (jexl2.lenient=true) if you still need that legacy behaviour. JEXL 1 is no longer supported, always use jexl.main.version=2 (the default). The JDK Groovy Provider is no longer supported, always use groovy.provider=grengine (the default). See further below for more details about the streamlining of the Scripting Engine.
  • Some of the "audit" log messages slightly changed their message text (mostly due to additional information being added). In case of any external log file monitoring setup that depends on the message text, the configuration might need to be adapted. Please check the "Log Messages" PDF document to see the text of all log messages.
Problem description: Credential Providers overriding each other

The problem is usually caused by a credential provider overriding another one; up until now, the SLS would not complain about it, and which one of the two was really used in the end was up to chance. A common case are SPNEGO-related login setups, where a configuration setting like this had been made (description from the "SLS Administration Guide"):

cred.provider.class.http=com.usp.sls.toolkit.http.cred.HttpStringCredentialProvider cred.provider.spnegotoken=http cred.provider.spnegotoken.cred.1.type=string cred.provider.spnegotoken.cred.1.source=header cred.provider.spnegotoken.cred.1.name=Authorization

A validation check in the SLS configuration handling has been added which will log an error message in this case, like

Credential provider 'http' already defined; use a different value for 'cred.provider.spnegotoken'

In that case, change this property name suffix from ".http" to something else like ".spnegotoken" The problem is that the value "http" in the second line defines an internal name for this provider, used as a unique key internally; and usually, there is already a "http" credential provider.

As a result, one of the two would not be active anymore. This was usually not an issue if a login used only SPNEGO credentials, but when it was supposed to be combined with other login procedures, there would be problems with some of them. To solve this, a different suffix must be used, like ".spnegotoken":

cred.provider.class.spnegotoken=com.usp.sls.toolkit.http.cred.HttpStringCredentialProvider cred.provider.spnegotoken=spnegotoken cred.provider.spnegotoken.cred.1.type=string cred.provider.spnegotoken.cred.1.source=header cred.provider.spnegotoken.cred.1.name=Authorization

Load-Balancing and Failover

  • The SLS now provides load-balancing support for most of its authentication adapters (LDAP, RADIUS, HTTP / Webservice and NTLMv2), as well as an improved type of failover. This new mode, called "Failover with a primary" uses the first system in the list as the one with highest priority, and will automatically fall back onto it, as soon as it becomes available again. Please see the corresponding chapter "Load-Balancing / Failover" in the "SLS Administration Guide" for details.

SLS Login Model

  • In action states in SLS login models that can perform an action using different adapters, like do.auth or do.changep with the model state, instead of with a separately configured mapping, for example model.login.state.5.name=do.auth plus model.login.state.5.adapter=ldap. This is especially useful if different adapters are needed for the same action in the same login model.

Custom Log Variable support

  • Whenever SLS log records are sent to a remote receiver using a SocketAppender, all custom log variables (Log4j MDC keys) are sent as well. In some cases, these variables may be used in special ways, e.g. as fields in Logstash / Elasticsearch. In case that those variables should have different names on the receiving end, or be blocked entirely, or additional variables should be added, the new configuration properties prefixed with "log.variables.*" can be used. Please see "SLS Administration Guide", chapter "Logging", subchapter "Add, block or rename logging variables" for details.

Logstash / Elasticsearch support

  • It has always been possible to simply send SLS log records to Logstash and Elasticsearch using a Log4j SocketAppender, and the Logstash Log4j plugin. But there was no control over the fields that would be created in Logstash (and, by extension, in Elasticsearch) based on the Log4j variables created by the SLS (or, rather, control was only possible through Logstash configuration). Now, the SLS provides the means to define custom Log4j variables to be created for certain messages, rename existing ones or whitelist variables entirely. Please see the "SLS Administration Guide", chapter "Logging" / "Logstash / Elasticsearch support" for more information.

New JSPs

  • The old, basic JSPs have been replaced with nicer looking, USP-branded JSPs with a more modern layout and behaviour. The new JSPs are easily customizable either by adapting the CSS stylesheet, or the include files for the different sections such as header or footing. Furthermore, the new JSPs support the smaller screens of mobile devices by automatically adjusting themselves.

New JEXL / Groovy functions

  • New JEXL/Groovy function function.getGroovyConfig(filename) which parses and caches Groovy configurations. Use normally instead of directly using a Groovy ConfigSlurper because if performs better when config does not change and it is also more robust against some memory issues that existed in the Java VM and/or in combination with Groovy versions in the past.
  • New JEXL/Groovy function function.clearErrors() clears all current errors from the current request and / or session. This allows to implement custom error handling and easily avoid displaying certain errors in special cirumstances.
  • The new JEXL variable +"sesticket"+ contains a SES ticket object, after the SES ticket credential provider has successfully processed an incoming ticket. See the "JEXL Guide" for details about the available methods for retrieving information from the ticket.
  • New JEXL function function.getLogMessageParameterValue(name) which allows to get the value of a parameter of the current SLS log message. This is only useful in the context of custom log variables defined with the new configuration properties prefixed with "log.variables.*".

Scripting Engine streamlined

  • Dropped support for JEXL 1 (jexl.main.version=1), always use JEXL 2 (jexl.main.version=2, the default) instead.
  • JEXL 2 is no longer "lenient" by default, meaning that by default exceptions thrown in scripts or when parsing scripts propagate out of the script and are thus reported with a very detailed, specific message. Set JEXL 2 to lenient (jexl2.lenient=true) to reactivate JEXL 1 legacy behavior, which usually results in an empty (null) result instead of an exception if something fails with an exception in a script or while pasrsing it. Using strict JEXL 2 is recommended, except for existing legacy configurations.
  • Dropped support for the JDK Groovy provider (groovy.provider=jdk), always use Grengine (groovy.provider=grengine, the default) instead.
  • There are still two modes of operating the Grengine Groovy provider, groovy.grengine.shareclasses=true|false (default true), which currently both have adavantages and disadvantages. Although not sharing classes is generally the goal as the default solution, because it is inherently more secure (session isolation) and relieves integrators of following some checks and conventions, Java VMs and Groovy still had serious memory management issues in that mode of operation in the recent past, so that it cannot be generally recommended, yet, without first testing memory management under load for the specific Groovy version and Java VM version and manufacturer.
  • Applied a fix that resolves an issue with garbage collecting Grovvy classes that could lead to an OutOfMemoryError (PermGen/Metaspace) if the SLS was used with groovy.grengine.shareclasses=false or made repeated use of a Groovy ConfigSlurper or of any other mechanisms that implicitly loads additional classes compiled from Groovy scripts.
  • If sharing classes between login sessions for Groovy scripts, (groovy.grengine.shareclasses=true), static non-final variables in Groovy scripts that contain the string "SlsIntentionallyShared" in their name result in a one-time log entry with level INFO (instead of WARN for such variables with other names). Before using this feature, ensure that no user information can leak via those shared variables.

Documentation Improvements

  • The following URL parameters supported by the SLS had not been documented at all, or only partially, until now: "target", "cmd=displayjsp", "cmd=cancel" and "cmd=pingsls". They have now all been documented in the "SLS Administration Guide".
  • The layout and formatting of the "JSP Taglib Guide" has been improved.
  • An invalid deprecation note about the SOAP frontend feature has been removed from the "SLS Administration Guide".

Various Improvements and Fixes

  • When slowdown was activated with a separate page for the waiting-message, the audit log message would contain "unknown" as the reason for the failed login; this has been fixed, so that the actual failure reason is now logged.
  • When an LDAP backend was selected using the JEXL function ldap.putLdapBackendSystem() and then was not reachable, the SLS would respond with a 500 server error; this behaviour was introduced lately with the 5.x release. This has been remedied, so that the SLS will now switch to the proper failedState and respond with a HTTP 200 code, and an error page.
  • Since SLS 5.x, the SLS handled certain cases of unavailable backends (e.g. with the HTTP adapter) as an internal technical error, and performed a model reset (instead of switching to the failedState). This has been fixed so that it behaves as it did before.
  • Basic support for other HTTP methods than GET, POST and OPTIONS. This is described in detail in a new chapter "HTTP Methods" in the "SLS Administration Guide".
  • A new audit error log message, "ERR_CONCURRENT_REQUEST", was added, which is logged whenever the SLS receives a request while already being processing another request from the same client.
  • Fixed a NullPointerException in the RADIUS adapter when the form for the response code ("ChallengeResponse.jsp") was submitted empty.
  • The SOAP frontend now allows to configure the size of its own pool of listener threads (before it was unlimited). Also, it now defaults to 200. Please see "SLS Administration Guide", "SOAP Frontend" for details.
  • A new WARN log message ("JEXL_ERROR_FUNC_IN_JSP_STATE") is written at startup time when the SLS validates the models and detects that JEXL functions like "function.failWithCustomError()" were used in actions of a JSP state like "get.cred", where the resulting behaviour is not the same as for non-JSP states (500 error response instead of jumping to the 'failedState'). Also, see "SLS Administration Guide", chapter "Model" for more explanations.
  • A new audit log message ("[SESSION_STARTED]") is written every time a new session is created, logging the session ID and the reason why the session was created (user needed to authenticate, or to get a missing authorization, or to perform a step-up from Member to Customer level etc.).
  • All cookies created by the SLS now automatically have the "Secure" attribute.
  • Whenever a 404 error occurred within the SLS (caused, for instance, by an invocation of an invalid JSP path), that 404 error was not visible anywhere in the log files, except when TRACE log level was active. Such errors are now logged on ERROR log level.
  • A bug in the initialization of the HTTP and the Webservice (WS) adapter was fixed, which would lead to problems when proxy settings were used with them.
  • Fixed a bug in the Webservice adapter configuration handling, which caused problems when the alias of a custom Webservice call was not all lowercased. There even was a corresponding warning in the "SLS Administration Guide" to use only lower-cased aliases. This has been fixed, so lower-case aliases are no longer mandatory, and the warning has been removed from the documentation.
  • Fixed a bug in the IdP Adapter that could under some circumstances lead to sending a success login Response with Assertion to the SP even though login failed at the IdP (and was logged as failed in the audit log on the IdP).
  • Added a new parameter mutableUsernameCredential to the do.saml.sp.handlemsg action in order to support changing usernames in case of an IdP Broker. See the section about the IdP Broker in the chapter "SAML IdP Adapter" in the "SLS Administration Guide" for how and when to use this setting.
  • The "performance" log file now contains 2 log records per request; one is written at the beginning of processing a request, and marks the request entry, and the second one, which is still written when the SLS is done processing a request, contains the familiar details about the time required in the various model states.
  • Fix: Changing the tenant dynamically in the model using the JEXL function session.setTenant() caused a model reset and a WARN log message. This has been fixed, so that the JEXL function can be properly used.
  • Some NTLM communication problems between SLS and DC will now trigger a failover, whereas they only resulted in a failed login until now.
  • In order to be more backwards compatible with existing installations, the PKI Adapter now allows an empty OCSP signer directory, but warns if OCSP checks are performed with no OCSP signer certificates present.
  • Fixed: The execution of the "do.auth" model state would occasionally log some error messages about missing credentials, such as "USERNAME" and "PASSWORD", when an adapter like the PKI adapter was used (where these credential types are never sent by the user). This has been fixed, so that there are no such confusing error logs anymore.
  • Fixed: The DataProtector JEXL function had a thread-safety bug, leading to occasional errors when decrypting a value using this function. These JEXL functions have now been fixed to be thread-safe.
  • Fixed: The Google Authenticator adapter now gives an INVALID_CHALLENGE_RESPONSE instead of with INVALID_CRED if the response was wrong, also if it was non-numeric, in accordance with behavior of other adapters that handle a response.

Removed Several Obsolete Features

  • Removed Siteminder Adapter (no productive setups exist).

Removed the "User Filtering" feature

  • The feature which allowed to configure a list of user IDs either in a blacklist or whitelist, and then allow or deny access based on that, has been removed completely. The reason is that this functionality was rarely used and can now easily be achieved with Groovy.

Removed the "stdout" logger support

  • Support for the named Log4j logger "stdout" has been discontinued. This logger would redirect the JVM stdout stream into the "sls.log" file. This was required a long time ago when not all application servers supported proper rotation of the standard-output-logfile. However, this feature is not only needed anymore nowadays, it is also potentially problematic if there are multiple web applications running inside the same cotainer, because one could then capture the standard output of all the other web applications too. For these reasons, this feature has been removed. Existing Log4j configuration files with the "stdout" logger can safely be udpated by removing this logger, but it also isn't a problem if the logger entry is still there; it's just not used anymore.

Removed "Statistics" logging functionality

Support for the named Log4j logger "statistics" and the related functionality has been discontinued. Mainly because it has become obsolete by now where the SLS is used mostly in appliances or managed environments, where other means exist for gaining statistical data from the log files.

Removed obsolete configuration signing feature

  • Up to this release, the SLS contained an undocumented feature which allowed USP to provide signed configuration for select customers. Since this functionality is not used by those customers anymore, the feature has been removed.

Secure Login Service Release 5.0.0.0 2016-03-23

Major Changes

  • Java 8: The SLS now uses and requires Java 8. Authentication filters (e.g. Tomcat Authenticator) for other webapps still support Java 6 and 7. See the "SLS Administration Guide" for requirements in detail.
  • SAML 2.0: The SP Adapter is now the recommended way to use the SLS as a SAML 2.0 Service Provider. The older solution based on the OIOSAML SP Servlet Filter is still supported, but no further development will take place there. It is recommended that existing installations migrate to the SP Adapter.
  • SLS JSP Tag Library: Now generally in all tag attributes (except basic inherited ones like 'id') JEXL/Groovy expressions can be used, e.g. <sls:inputField ... size="${mySize + 2}" ... />.

PKI Adapter

  • Dynamic selection of trusted CA and OCSP signer certificates as well as of CRL and OCSP checks to do during login with configurable trust groups. Allows to define trust groups that trust only a subset of the configured CA certificates and/or OCSP signer certificates and limit OCSP/CRL checks per trust group. This allows to authenticate more flexibly and especially more strictly depending on client and application. Trust groups can be defined with a small set of new properties with format pki.trustgroup.<alias>.<suffix>=<value>. Trust groups can be selected in the login model with a new JEXL/Groovy function pki.setTrustGroup(String alias). See "SLS Administration Guide" and "SLS JEXL Guide" for details.

SAML IdP and SP Adapters

  • IdP-initiated SAML login is now supported by both the SP and the IdP Adapters. For the SP, no additional configuration is needed, except to slightly adapt the login model; for the IdP the desired SP for login is set with a new JEXL/Groovy function idp.setLoginSp(spEntityIdOrAlias) and can be selected by the user in the existing (modified) IdpSpSelection JSP. See section "Login Model: IdP-initiated Login" in chapter "SAML IdP Adapter" and section "Simple Login Model" in chapter "SAML SP Adapter" in the "SLS Administration Guide" for how to configure and use the new feature in detail.
  • SAML IdP and SP adapters have learnt a new configuration property, idp.redirectWithMetaRefresh and sp.redirectWithMetaRefresh, which instructs the adapters to use the HTML "meta refresh" feature instead of an HTTP Redirect (status code 302). This feature can be used to work around a restriction in some major browsers that limit the number of redirects they follow. Refer to the IdP/SP adapter documentation in the "SLS Administration Guide".
  • New property sp.default.idp for defining the default SP to use for login if not specified otherwise. See the "SLS Administration Guide" for how the IdP is selected in detail.
  • The property sp.credential.username.attrname can now also indicate the friendlyName XML attribute (not only the name XML attribute) of the SAML attribute in the assertion. First it is searched by name then by friendlyName in the assertion.
  • The property sp.assertion.validity.offset.allowed.secs is now considered correctly for the comparison that the current time is less than notBefore in the Assertion (offset was considered in the wrong direction before).
  • The IdP now supports assertions without attributes. Previously at least one attribute was required. In case of no attributes, the AttributeStatement is removed from the assertion. This also eliminates former compatibility issues with SAML login for Google Apps.
  • Fixed a bug in the do.saml.idp.create.assertion action: Formerly the created assertion was practically empty and only fully populated during the do.saml.idp.sendmsg action, i.e. too late to make custom changes, which had been the idea for the do.saml.idp.create.assertion action in the first place. Now the created assertion contains already everything except assertion attributes (and except encryption and signature), which can still be customized freely. See the chapter "SAML IdP Adapter" in the "SLS Administration Guide" for details how to do this.
  • New property idp.assertion.attributes.legacyFormat which defaults to true if not explicitly indicated, for backwards compatibility. If set to true, fixes an issue regarding the XML validity of assertion attributes. Does not default to false because not all SPs can handle base64 attributes if the assertion was sent encrypted.

Documentation

  • There is a new chapter "Recommended Settings" in the "SLS Administration Guide", which lists all kinds of recommended configuration settings for various software components involved in running an SLS instance (Java VM, Tomcat, HSP, SLS...).

Various Improvements and Fixes

  • Fixed: When multiple cookies of the same name, but different paths, were created by the SLS (for example with the corresponding JEXL functions), only one of those cookies would ultimately be set in the response, and a misleading warning log message was written. This has been remedied, so that the same cookie can now be set multiple times, with different values for different URI paths.
  • The LDAP-adapter JEXL function ldap.putLdapBackend() also change the
    state of the internal failover backend system management, adding the given backend to the list of failover-backends for the given alias. In that regard, the function had a persistent impact on the state of the SLS, which could lead to severe issues in cases where a failover was actually necessary, and then resulted in an inconsistent state of the SLS that would even require a restart. This has been fixed so that this JEXL function now really only affects the current session.
  • The failover mechanism had a bug which could lead to failover attempts, even if only one single backend was configured for any given backend type (e.g. LDAP). That was fixed. If there are less than 2 backends configured for a certain backend operation, no failover will be attempted.
  • There was a global lock used by the failover mechanism, which lead to users getting 500er error responses when trying to access the SLS while a failover was still pending. This lock has been removed entirely.
  • Bumped included USP WSDL Tool to the Java-8-enabled version 2.0.0.
  • The logfile of the SOAP / Webservice frontend of the SLS did not support logging the client- and request-correlator header values of the incoming request like all other SLS log files. This has been fixed so that the SOAP frontent logs can now easily be correlated with the other SLS logs. NOTE: The Log4j variables MUST be "{cc}" and "{rc}" in order for it to work properly.
  • Fixed a bug related to a change of the "requested page" within an existing login session. While the change was registered and a WARN log was written, the new value was not stored, so the final redirect after the login would potentially go to the wrong location. This has been fixed, and also the log message severity has been reduced to INFO.
  • Made the JEXL expression header.host respect the configuration setting auto.host.header.enable.
  • Fixed a memory leak in the thread-local storage.
  • Variables persisted with persist.variable are recreated as empty strings if they did not exist before persisting to the cookie to eliminate the use for checks for existence for a non-null variable with the given name.
  • The JEXL/Groovy functions session.getLanguageCode() and session.getCountryCode() have been deprecated; use the more consistently named new functions session.getLanguage() and session.getCountry() instead.
  • Upgraded Groovy from version 2.2.2 to 2.4.5.
  • The configuration property jsp.globalerror.duplicates has been removed.
  • Fixed a bug in the HTTP adapter that failed to process HTTP responses without a response body, e.g. 204 No Content.

Removed Axsionics adapter

  • The obsolete Axsionics adapter has been removed.

Removed the ancient "Triggers" feature

  • The obsolete and rarely used feature called "Triggers" has been entirely removed. NOTE: This has nothing to do with model triggers. It was an old mechanism that allowed to trigger certain actions during a flow based on the user ID, using either the model state "do.trigger" or the JEXL function "function.checkTriggers()". The same kind of functionaliy can nowadays be implemented in many, and more flexible ways using conditional model actions or states, JEXL and Groovy scripts etc.

The "Triggers" feature had to be enabled with the configuration property "triggers.enabled=true" (which is not supported as well anymore). So you may need to search your configuration for this property to check if that functionality was used. If so, the configuration will have to be adapted using the regular conditiona actions and scripting mechanisms.

Secure Login Service Release 4.40.0.0 2015-11-18

New JEXL functionality

  • The new JEXL functions function.getConfigPropertyEntriesWithPrefix(String), function.getConfigPropertyNamesWithPrefix(String), function.getConfigPropertiesWithPrefix(String), function.hasConfigProperty(String) and function.isConfigPropertyOn(String) allow to implement more extensive, customized configuration handling. Please see "SLS JEXL Guide" API documentation of these functions for details.

  • The new configuration property persist.variable allows to configure one or multiple JEXL variables to be automatically persisted in the reverse proxy session. So it's possible to have certain variables to be carried over from a login flow to a change password flow etc. Please see "SLS Administration Guide", chapter "Expressions" for details.

  • The JEXL function function.getLocalizedMessage(String key, String defaultValue) allows to provide a default text to be used if no message was configured for a given message key.

  • The SLS now responds to SLS "ping" requests ("?cmd=pingsls") in case there were SLS startup errors with HTTP 200 and SLSStatus header 500, instead of previously with HTTP 500 and no SLSStatus header.

Various Improvements

  • The new configuration property auto.host.header.enable=true allows to enable automatic setting of the correct Virtual Host name in the current request. This eliminates the need to configure the SRM directive HGW_ForceHost for certain login procedures like SAML. Also, with this feature it is no longer necessary to use a HTTPS (SSL) connection between the SRM and the SLS.

  • Fixed an LDAP adapter issue where the principals for a custom LDAP operation would not be used if the property names were not all lower-cased, and instead the default tech principal was used.

Secure Login Service Release 4.39.0.3 2016-01-25

  • Fixed a memory leak in the thread-local storage.

Secure Login Service Release 4.39.0.2 2015-10-29

Google Authenticator Improvements

  • The JEXL function googleauth.getSecret() now supports parameters which allow to define if the resulting base32 string should be stripped of any padding characters (which are causing problems on some mobile platforms) and if the string should be formatted in a human readable format (for displaying it to the user).

Various JEXL Improvements

  • The new JEXL function function.hmacSHA256bytes returns a byte array instead of a hex-encoded string.

  • The new JEXL functions function.base32encode(byte[]) and function.base64encode(byte[]) encode a given byte array instead of a string.

Secure Login Service Release 4.39.0.1 2015-10-28

Transaction Signing Improvements And Bugfixes

  • All req parameter values are now stored in the session instead of only per request, which allows to access these values with the JEXL/Groovy function function.getReqParameterValue() in later requests, which can even be in in different login models, e.g. set in trxinit and queried in trxcancel.
  • The trxcancel action now uses the rurl return URL from the so-called "req parameter" header to the SLS even also if ignore.requested.page=true. (A HSP-TRX-Cancel-Url header sent during trxinit still has precedence, if present, independently of the ignore.requested.page property.)

Various Improvements And Bugfixes

  • Fixed a bug that could cause JEXL/Groovy expressions not to be evaluated for properties with numeric values.
  • More helpful error message if a configured Groovy script directory exists and is a directory, but its files cannot be listed (due to lacking permissons).

Secure Login Service Release 4.39.0.0 2015-10-13

Google Authenticator Adapter

  • A new Adapter that allows to authenticate with the Google Authenticator. See the "SLS Administration Guide" for how to configure and use the new adapter.
  • New JEXL/Groovy function function.hmacSHA256(), plus several new functions specifically for the Google Authenticator Adapter.

SAML 2.0

  • Both IdP and SP adapter now support HTTP POST Binding for all incoming and outgoing SAML messages.
  • Two new JEXL/Groovy functions idp.getSpInfo(aliasOrEntityId) and sp.getIdpInfo(aliasOrEntityId).

Secure Login Service Release 4.38.0.2 2015-09-02

Various Improvements And Bugfixes

  • The NTLM adapter could run into an infinite loop in some specific (rather rare) cases of concurrent login attempts, and with a certain model configuration. This issue has been eliminated.

  • New JSP tag doJexl which behaves like getJexl except that no output is produced.

Secure Login Service Release 4.38.0.1 2015-08-24

Various Improvements And Bugfixes

  • Various improvements were made in the HTTP and Webservice-adapter, as well as some JSP tags and other core functionality to reduce the memory footprint per session.

  • New configuration property "log.disable.log4j.vars" allows to disable the creation of Log4j MDC variables for all request headers and parameters. This can be desirable in some (rather rare) use-cases where 3rd-party appenders are used which just forward all this information to some kind of log server, where the availability of variables for request parameters with potentially sensitive information (username, password) can be a problem.

Groovy Improvements

  • The "Grengine" Groovy engine is now active by default. Additionally, a new configuration setting has been introduced: groovy.grengine.shareclasses. This new setting is also active by default. These changes reduce memory consumption and improve performance of script execution considerably.
  • Groovy version upgraded from 2.2.2 to 2.4.4.

Tomcat 8 Authenticator

  • New: SES Authenticator for Apache Tomcat 8. Support for the following formerly deprecated and undocumented properties has been removed:
    • system property "com.usp.sls.appserver.ticketauth.configfile": use "com.usp.sls.authenticator.configfile" instead.
    • Authenticator config properties "headername", "keyindex", "authentication.signkeyfile", "authentication.authmethod": use their equivalents documented in the Administration Guide. Please also note the following changes:
    • The SES Authenticator is now registered in "Authenticators.properties" with the identifier "SESAUTH" instead of the misleading "SESTICKET".
    • The "uspauth.properties" config file is now processed in UTF-8 encoding.

Secure Login Service Release 4.37.0.1 2015-08-12

Documentation Improvements

  • New chapter "JSP" which explains how to deal with and adapt the JSP files in the SLS, how displaying error messages can be fine-tuned through some JEXL functions and more.

  • Clarifications for the "WS Adapter" (Webservice) chapter, which explain in more detail how proxy-settings, connection timeouts or a list of accepted SSL common names are configured (features derived from the underlying HTTP adapter).

Various Improvements And Bugfixes

  • New: The HTTP adapter now creates additional JEXL variables for the last HTTP response it received from the backend. One new variable, "response.holder", contains a direct Java object reference to the Apache HttpClient response holder, so that full access to all information in that class is made available, if necessary. Furthermore, "Set-Cookie" headers are processed specifically, and for each cookie set in the response, a JEXL variable named "response.cookie.<name>" is created with the value of that cookie. See "SLS Administration Guide", chapter "HTTP Adapter", for details.

  • Fix: The SAML IdP adapter now signs error Response messages (in response to AuthnRequest messages from an SP) if configured to sign messages (idp.sp.<no>.message.sign). Previously this was only done for success Response messages but omitted for error Response messages. The SAML SP adapter now verifies the signature of error Response messages before accepting the response. Previously, the signature was not verified for error Response messages, only for success Response messages.

  • Fix: The PKI adapter now logs a warning whenever a client is authenticated whose certificate is valid but was signed with a CA certificate that is now expired.

  • The obsolete "Info Portal" functionaliy was removed from the SLS, since it provides no useful functionality beyond the management GUI.

Secure Login Service Release 4.37.0.0 2015-07-29

  • Fix: The SAML IdP adapter did not consider the SP metadata when processing a request that did not contain a NameIDPolicy element. The IdP adapter has been changed to search the NameIDFormat elements in the SP metadata for a NameID to use in this case.

  • New: The SAML SP adapter now supports using the NameID value of a Subject in a SAML Assertion as the username credential. Previously the username credential was always extracted from an Attribute contained in the Assertion. Several properties were added to enable configuring this feature both globally as well as on an IdP-specific basis.

  • Fix: The URL encoding in the SLS always substituted blank characters in URL encoded values with "+" signs. While this is a de-facto standard until this day, it's not really conforming to official specifications, and it caused problems in AAI setups with the HSP, if usernames or passwords contained blank characters. This has been changed so that blanks are now substituted with the correct "%20" string. It is possible, however, to re-activate the legacy behaviour with the new configuration property "url.encoder.legacy=true", if necessary.

  • New: SP adapter supports more standard ways for indicating how to decrypt an encrypted assertion.

  • New: Added support for specific key pair alias in SAML 2.0 IdP and SP adapters to facilitate IdP and SP certificate migration. See the "SLS Administration Guide", chapter "IdP Adapter", for detailed information about this feature. The documentation includes an example migration procedure.

Secure Login Service Release 4.36.0.1 2015-07-06

  • New: The HTTP adapter now supports separate, dedicated monitoring URLs, in cases where the actual backend URLs (as used for authentication or custom HTTP calls) contain session-specific JEXL values. See "SLS Administration Guide", chapter "HTTP Adapter", for details.

  • Fixed: A racing condition in the J2EE servlet authentication filter, caused by some code which was not thread-safe. As a result, the user ID could sometimes not be extraced from the request header correctly, and the login would fail. This problem would typically arise under heavy load.

Secure Login Service Release 4.36.0 2015-06-19

Various Improvements And Bugfixes

  • Fix: Fixed a Java 8 incompatibility issue in OIOSAML SP. The SLS can now be used with a Java 8 runtime environment.

Secure Login Service Release 4.35.0 2015-06-06

Various Improvements And Bugfixes

  • New: URLs defined in the HTTP/WS adapter that evaluate to "off" when the adapter is loaded are not added to the list of failover URLs. This allows to separate configuration of failover URLs from individual HTTP callout configurations. See the "SLS Administrator's Guide" for full details.

  • Fix: Fixed bug that function.logCustomMessage(id) would throw a null pointer exception if the id is not defined in configuration. Now an error is logged an the function throws a JEXL runtime exception.

  • Fix: Failover in HTTP/WS adapter works in more situations (unknown host, timeout).

  • Fix: Evaluating a script as a Groovy expression that failed with a custom error would cause a 500 error instead of normally failing to the failed state of the corresponding model step. Example content of script "fail.script": function.failWithCustomError('sls.invalid.credentials', 'no access'). The following calls would cause the 500 error: #{runscript.jexl('fail.script')} and #{runscript.groovy('fail.script')}. The following calls would work as expected: ${runscript.jexl('fail.script')} and ${runscript.groovy('fail.script')}. Now all four calls work.

  • Fix: OIOSAML SP credential provider again creates JEXL variables for multi-value SAML assertion attributes assertion.attribute.<friendlyname>.<index>.

Secure Login Service Release 4.34.0.2 2015-02-25

Various Improvements And Bugfixes

  • Fixed various issues created by the combined use of the self-redirect feature (SLS responds with a 302 instead of a 200 to POST requests to avoid browser replay attacks) with the parameter checker.

  • Eliminated the dependency of the parameter checker to having the parameter "validate" set to "true" for any action mapping in the struts configuration.

Secure Login Service Release 4.34.0.1 2015-01-27

Various Improvements And Bugfixes

  • New JEXL function function.deleteOpticalTokenImage() allows to delete a token image file, created with the JEXL function storeOpticalTokenImage, in order to keep the filesystem clean.

  • Fixed a bug in the SLS JSP taglib, where the tag "sls:button" would not create correct (current model trigger) URIs for commands such as "logout", if the dynamic URI functionality was enabled.

  • Fixed a bug in the SAML assertion credential provider (which is used with the OIOSAML SP), which could result in invalid JEXL variables for assertion attributes, if those attributes had no "FriendlyName".

Secure Login Service Release 4.34.0 2015-06-01

Various Improvements And Bugfixes

  • The WS (Web-Service) adapter did not handle responses with namespace definitions in subnodes correctly, at least not in certain cases. This has been fixed; the adapter now cleares all namespaces from the response it received, before applying the XPath expressions that were built based on the response template.

  • The JSP tag "sls:message" evaluated JEXL expressions in the "key" attribute too late, if the expression was used to contain pre-defined special values such as "global.error.msg". This has been fixed, so that if the "key" attribute is a JEXL variable which evaluates to "global.error.msg" or any one of the other predefined keys, it will be properly handled.

  • In rare cases where the user information stored in the SLS user info cookie had to be split into multiple cookies (because of the large data size), there was a potential issue with cookie decoding, if the user info data size shrank in a later SLS access back to only one single cookie. This has been adressed, so decryption and decoding of this cookie always works as required.

Secure Login Service Release 4.33.0 2014-11-26

New LDAP Adapter Functionality

  • New: LDAP adapter now supports creating or removing sub-contexts (such as a DN for a new user). Up to now, the LDAP adapter could only add, update or delete attributes on existing objects; with the new create and remove operations, it is now possible to create new LDAP objects from scratch or remove them. See "SLS Administrator's Guide", chapter "LDAP Adapter", for details.

New SAML JEXL Functions

  • Support for the "ProxyCount" element in a SAML AuthnRequest has been added through the new JEXL functions sp_authn_request.setProxyCount(), idp_authn_request.getProxyCount() and idp_authn_request.hasProxyCount(). See "SLS Administration Guide", chapter "SLS as SAML 2.0 IdP Broker", for details.

Various Fixes

  • The configuration of Service Providers in the IDP-adapter no longer requires a continuous numbering of the configuration properties, starting with 1, e.g. idp.sp.1..., idp.sp.2... etc. The numbering can now start at any value and can also have gaps. Correspondingly, the same is true for the configuration of Identity Providers in the SP-adapter, e.g. sp.idp.1 etc. These properties also no longer need to be numbered continuously.

  • The PKI adapter CRL verification succeeds in the case where both CRL via URI and CRL via local files is active (in this order) in the case where URI CRL verification was successful and no local CRL was present for the same CA. Checking multiple CRL plugins now stops at the first successful CRL verification.

  • The model states do.saml.idp.send.msg and do.saml.sp.send.msg do not require the parameter param.continue anymore for the Single Logout flow (or any other flow, for that matter). The action which sends SAML messages has been changed to make sure that the model will always advance to the next state when a new request arrives, no matter if it is a GET request or a POST request. The parameter can now safely be removed from existing models; if it is still in the model, it will just be ignored.

  • The SAML IdP no longer fails to send an error Response if the AuthnRequest contained no ID; the SAML SP no longer fails to send an error LogoutResponse if the LogoutRequest contained no ID.

Secure Login Service Release 4.32.0 2014-10-31

New SAML Service Provider Functionality

  • New: There is a new "SP-adapter" in the SLS which implements a SAML 2.0 service provider. It is, however, currently limited in functionality and supported bindings, so it is not a replacement for the OIOSAML SP yet (see "SLS Administration Guide" for details).

New SAML Identity Provider Functionality

  • New: The new model state do.saml.idp.create.msg allows to create the response message in a separate step, before sending it to the SP, in order to further manipulate the assertion, adding additional elements etc. Also, it is possible to directly create a SAML error response, so that the IdP can respond with a SAML error based on any arbitrary logic (see "SLS Administration Guide" for details).

  • New: The new model state do.saml.idp.create.assertion allows to create the assertion in a separate step, before sending it to the SP, in order to further manipulate the assertion, adding additional elements etc.

  • New: JEXL variable idp_assertion provides simplified access to the new assertion created in the model state do.saml.idp.create.assertion.

  • New: JEXL function idp_assertion.getOpenSamlAssertion() provides access to the OpenSAML Assertion object.

  • New: JEXL variable idp_authn_request provides simplified access to the current "AuthnRequest" in the IDP session, sent from the SP. This variable is created as soon as there is an "AuthnRequest".

  • New: JEXL function idp_authn_request.getOpenSamlRequest() provides access to the OpenSAML AuthnRequest object.

  • New: JEXL function idp_authn_request.hasIdpList() allows to check if the AuthnRequest contains an IDPList element, with one or more IDPs.

  • New: JEXL function idp_authn_request.getIdpList() returns a list of OpenSAML IDPEntry objects.

  • New: JEXL function idp_authn_request.idpListContains(String entityID) allows to check if the IDPList in the AuthnRequest contains a certain IDP entity ID.

  • New: JEXL function idp_authn_request.containsRequestedAuthenticationMethod() allows to check if the AuthnRequest contains a "RequestedAuthnContext" which contains the given authentication method URN, such as "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI" for certificate login.

  • New: JEXL function idp_authn_request.getRequestedAuthnContextComparison() allows to retrieve the "RequestedAuthnContextComparison" string value, such as "EXACT", "MINIMUM", "MAXIMUM" or "BETTER".

Various Fixes

  • Fixed: Due to a bug in JEXL, an expression like the following could leak JEXL variables between login sessions of different users in the worst case: ${myArray = [myVar1,myVar2]}. The array was globally only evaluated once, so that it remained at the value calculated for the first user forever. This has been fixed, although within a login session, the array is still only evaluated once per JEXL expression string or script. Therefore it is recommended not to use arrays in this way or to use Groovy instead.

  • Fixed: The functions ldap.escapeDNValue(String) and ldap.escapeFilterValue(String) no longer only escape values if ldap.enable.escaping is true, now always escaping independently of the configuration property.

  • Fixed: LDAP DNs in searches are no longer escaped automatically if ldap.enable.escaping is true, must now be explicitly escaped with ldap.escapeDNValue(String) where desired. The previous behavior was inconsistent (DNs in bind were not escaped, only DNs in custom searches) and, contrary to filters, escaping DNs automatically causes more harm than good in practice and helps comparatively little to increase security.

Secure Login Service Release 4.31.0 2014-10-13

New Functionality

  • New: The SPNEGO adapter can now parse MS Kerberos login data in the received Kerberos ticket and determine whether the login of the client was by password or by certificate (i.e. by smartcard or a similar crypto token). Sets two new boolean JEXL variables, spnego_ms_kerberos_password_login and spnego_ms_kerberos_certificate_login after each successful SPNEGO login. See "SLS Administration Guide" for more details.

Secure Login Service Release 4.30.0 2014-10-06

New Functionality

  • New: JEXL function function.getClientCertificateExtension(String extensionOID) allows to retrieve the string value of the given extension from the current client certificate credential (in a PKI adapter login flow). See "SLS JEXL Guide" for details.

  • New: JEXL functions function.failWithCustomError(String error, String reason, String ... args) allow to create an error with a parameterized custom message. So, the text message in the message resource file, referenced by the key in the first argument, can contain placeholders like {1} and {2} (up to 6) which will be replaced by the corresponding additional arguments. See "SLS JEXL Guide" for details.

  • New: JEXL function function.arrayMatches(String[] array, String regex) allows to check if a String array contains a value which matches the given regular expression. There are two versions of this method; one takes an array as the first parameter, one a single string, so that it works in both cases, and is completely transparent to the caller.

Groovy Integration

  • New: Besides the standard Groovy provider, based on the Groovy JDK, there is now an additional provider, based on the Groovy JDK plus and additional library, Grengine. Use the new property groovy.provider to select a provider, jdk (default) or grengine.

  • New/change: It is now possible to define multiple Groovy script directories, using groovy.classpath.add.scriptdir.<suffix>. Conversely, when running a Groovy script with runscript.groovy(...), the directory that contains the script file is no longer added to the Groovy classpath.

  • Removed: The setting groovy.script.timeout.secs has been removed, because it fundamentally cannot be made to work as desired, due to the nature of the Groovy JDK and the Java VM.

Various Fixes

  • If a URL in the HTTP adapter contained JEXL or Groovy expressions in the URL part (not the query), failover would not work anymore. This has been fixed so that, depending on the HTTP response codes, a connection check should still work, even if the URL contains expressions that cannot be resolved.

  • Fixed: The JEXL function function.arrayContains(Object[] array, Object value) could not be used in cases where the first parameter was a variable which could be either an array or a single string. This is specifically the case with some LDAP adapter JEXL variables for group memberships; if a user is in multiple groups, these variables are created as arrays. If the user is only in one group, they are created as a single string. This is a limitation of the underlying JNDI API and cannot be solved in the LDAP adapter. For this reason, a new JEXL function of the same name has been added, which takes a single string as the first parameter: function.arrayContains(Object holder, Object value). JEXL will automatically use the right function, depending on if the first parameter is an array or not. Therefore, this is completely transparent for the caller (script / condition).

  • Fix: If the SAML Identity Provider had to respond with an error message, the top-level status code was not always conforming to the SAML standard. This has been fixed, so that error responses now always contain one of the four official top-level status codes, and a nested detail status-code.

  • All SLS components are now uniformly built with JDK 6 and with JDK 6 as target. (Previously, some components were still built for JDK 5 target bytecode, although JDK 5 compatibility had already no longer been supported for some time.)

  • Fix: When an authenticated client was redirected back to the SLS due to a missing authorization, the JEXL function "session.getMissingAuthorizations()" would not always return the correct list of authorizations. Sometimes, authorizations that the user already had were also included in this list. This has been fixed, so that this function will not always only return the list of authorizations that the location required, but the user not yet has.

Secure Login Service Release 4.29.0 2014-08-26

New Functionality

  • New: JEXL function function.getConfigProperty(String name) allows to retrieve a value of a configuration property. This can be useful to separate typical configuration values from JEXL or Groovy scripts.

  • New: JEXL function idp.getSamlMessage() that allows to access the last received SAML message as an OpenSAML 2.0 object for custom handling in the login model.

Various Fixes

  • Fixed: The SAML Identity Provider performed a check on a "RequestedAuthnContext" element in an authentication request, and if that element contained a "comparison"field with a different value than "exact", an error response was sent back. This check has been removed, so that it is now up to the model configuration to decide how to handle the authentication request.

  • Fixed: In the LDAP adapter, it was possible that the JEXL variable containing the user DN from the last search was lost during a bind authentication operation under certain circumstances. This could pose a problem for subsequent LDAP operations which required the user DN value. This has been fixed, so the DN variable will always be kept correctly.

Secure Login Service Release 4.28.0 2014-07-18

New Functionality

  • New: SLS command line tool that allows to get SAML 2.0 Identity Provider metadata without a running SLS. The new tool, "SLS Tool", also incorporates the former "OIOSAML Config Generator" command line tool. Both can now conveniently be used from the same command line tool that comes in a single fat java JAR file. See "SLS Administration Guide", chapter "Support Tools", for details.

  • New: The new JEXL prefix passwordpolicy provides various functions which allow to access information about the local SLS password policy.

  • New: The model state get.localpasswordpolicy loads the password policy from the local XML file, independently of the password change adapter type (or even if there is none at all).

  • New: It is now possible to use JEXL expressions for the parameter (or property) of the model state show.jsp.

  • New: New parameter for model state do.logout: url.absolute.allow. If set to true, an absolute URL given in the target request parameter is used and not forced to the same host as where the SLS was accessed; default is false for backwards compatibility. Also, the existing optional redirect blacklists or whitelists can be used to restrict allowed redirect URLs.

Various Fixes

  • Fixed: Default of groovy.script.timeout.secs changed to 0 seconds (no timeout), because under some circumstances the timeout does not work as advertised (probably an intrinsic issue of Groovy itself). See the "SLS Administration Guide" for more details.

  • Fixed: Names of model state parameters could not use camelcase naming, so something like model.state.10.param.customValue did not work. This has been fixed, so that the names of model state parameters are now completely case-insensitive.

SAML 2.0 Identity Provider

  • Fixed: Support for SP Metadata with several AssertionConsumerService entries for the same binding.

  • Fixed: SAML credential is removed/ignored in the do.saml.idp.sendmsg action. Normally, the SAML credential only lives between an initial request and the do.saml.idp.handlemsg action where the SAML message is moved to the SLS' SAML context. However, e.g. in case of NTLM, there can be a second request with identical GET parameters, including the SAML AuthnRequest, which caused login to fail in the end unless the SAML credential was explicitly removed in the model before the do.saml.idp.sendmsg action.

Secure Login Service Release 4.27.0.2 2014-05-28

  • Changed: Eliminated the need to configure an .id for any selection list variables to be parsed from a SOAP response in the Webservice adapter. If no variable is configured for the ID, one will be generated for each selection item dynamically.

Secure Login Service Release 4.27.0.1 2014-05-27

WS Adapter

  • New: XML tags in response templates can contain a pseudo attribute slsvariable to denote the whole node corresponding to the XML tag. This is useful e.g. in combination with the selection feature, where the id and text may often be nested below the node.

Secure Login Service Release 4.27.0.0 2014-05-23

  • New: WS Adapter, for generic XML incl. SOAP Web Service callouts, based on the HTTP Adapter. Allows to define response templates that are automatically mapped to JEXL/Groovy variables of different data types, allows to map SOAP faults to different types of errors, allows to map WS result data to a selection in a JSP and then to automatically extract the selected XML data using the new do.select action, and many more features. See the "SLS Administration Guide" for detail.

  • New: The JEXL function function.getSlsErrorCategory returns the category of the last SLS error message, which is either AUDIT for audit messages, USER for user-related errors (such as invalid credentials), "SYSTEM" for technical errors in the SLS and "SYSTEM_BACKEND" for technical errors in the authentication backend system.

  • New: Upgrade from Groovy version 2.1.9 to 2.2.2.

  • New: Improved documentation of SAML SP JEXL/Groovy functions for getting assertion and attributes.

  • New: The LDAP adapter now also supports attribute "add" operations. They work similar to the "update" operation, as far as the configuration is concerned. The properties just contain an .add. part instead of an .update. part. See "SLS Administration Guide", chapter "LDAP Adapter", for details.

  • Fixed: If an exception occurs in a Groovy expression (i.e. not in a Groovy script file), the script class name indicated in logs is now GroovyExpression instead of the generic default Script1.

Secure Login Service Release 4.26.0.4 2014-07-16

New Functionality

  • New: The feature which allows to let the SLS respond with a HTTP 302 response code (instead of an HTTP 200) to a POST request, has been improved. This feature allows to prevent attempts for malicious users to retrieve data posted by another user in the same browser instance by pressing the "back" button multiple times, triggering the automatic re-post feature of most browsers. However, this functionality is disabled by default for reasons of backward compatibility. Now it also can be restricted to certain user-agent types, such as rich clients. Note that a new configuration property has been introduced to enable this functionality (and for better consistency with the naming of corresponding properties). The new property is called redirect.response.to.post. Set it to true to enable the automatic redirect response. This property also replaces the now deprecated property selfredirect.enable.

  • New: The property redirect.response.whitelist.regex allows to define when NOT to respond with a 302 redirect to a POST request, based on the user agent header. The purpose of this functionality is to avoid 302 responses for rich clients which expect a 200 response. Set the property to a regex value that matches with the user agent header of the rich client, e.g. redirect.response.whitelist.regex=httpunit.*. Note that if this property is set, the SLS will respond with a 302 code to all clients which do NOT match the whitelist. If both a whitelist and a blacklist are defined, the blacklist will be used.

  • New: The property redirect.response.blacklist.regex allows to define when to respond with a 302 redirect to a POST request, based on the user agent header. The purpose of this functionality is to enforce 302 responses for browser clients. Set the property to a regex value that matches with the user agent header of the browser client, e.g. redirect.response.whitelist.regex=Mozilla/[123].. Note that if this property is set, the SLS will respond with a 302 code only to all clients which do match the blacklist. If both a whitelist and a blacklist are defined, the blacklist will be used.

Various Fixes And Improvements

  • Fixed: The PKI adapter only used the "Subject DN" in a client certificate to look up and find the matching CA certificate, in order to verify it. But in cases where a Certificate Authority got migrated to new certificates with the same "Subject DN" but new keys, this mechanism didn't work anymore. The adapter has been improved to now first look for a matching key based on the "Authority Key Identifier" in the client certificate. Since this is not a mandatory field, it still falls back on the "Subject DN" if no key identifier can be found.

  • Fixed: In the RADIUS adapter the property radius.tokencode defaulted to concat even when explicitly set to the empty string. This has been fixed. Note that due to backwards compatibility concat remains the default setting.

  • Fixed: In release 4.26.0, a bugfix concerning the do.redirect state introduced another new bug. As a result, the do.redirect state now always used the target parameter URL instead of its property URL, if such a parameter was available. This is wrong, because the target parameter should really only be used by the do.success and do.logout states. This has been fixed for this release.

  • Fixed: In certain cases, when an error was intentionally caused using one of the JEXL functions function.failWithCustomError() or failWithAuthenticationError(), the SLS would not jump to the correct failedState, but instead generate an HTTP error 500. As a result, the session was invalidated, and the model started from scratch. This has been fixed, so that the error handling now always works as intended.

  • Fixed: The Groovy mechanism in the SLS created an internal variable named "sls", which resulted in unnecessary WARN logs about potential variable name clashes, as soon as both Groovy and JEXL scripts were used in the SLS. This internal variable has been eliminated, so no unnecessary WARN logs are written anymore.

Secure Login Service Release 4.26.0.3 2014-05-13

  • Security fix: Fixes a vulnerability in Struts 1. The vulnerability exists only if the SLS runs in Tomcat 8 (but not with earlier Tomcat versions or other web containers that are not based on Tomcat 8) and only if HSP request parameter filters are sufficiently open. See the respective USP Security Advisory for details.

  • New: The JEXL function function.getSlsErrorCategory returns the category of the last SLS error message, which is either AUDIT for audit messages, USER for user-related errors (such as invalid credentials), "SYSTEM" for technical errors in the SLS and "SYSTEM_BACKEND" for technical errors in the authentication backend system.

Secure Login Service Release 4.26.0.2 2014-05-13

  • Upgrade: The OIOSAML SP library has been upgraded to a bugfix release (1.0.24) which properly implements the SES session check patch, while still maintaining the SLO functionality.

Secure Login Service Release 4.26.0.1 2014-05-03

LDAP Adapter

  • Fixed: The JEXL variable ldap.search.dn wasn't cleared before an unsuccessful filtered search, which could lead to erronuous behaviour, if the variable already contained a value from a previous lookup. This has been fixed, so that the variable is cleared each time a search is performed.

Various Fixes And Improvements

  • Fixed: During a login slowdown, the waiting message displayed in the login page (not the separate JSP) did not always show the correct time.

  • New: The model state "do.validatepassword" will now also compare the two credentials NEWPASSWORD and NEWPASSWORD2, if (and only if) both are available. By default, it does not enforce the availability of the NEWPASSWORD2 credential; this can be done with the existing state property, where a list of required credentials can be specified.

  • Fixed: JEXL/Groovy expressions and scripts are generally only compiled once per script text resp. per script file name and path, but, due to a bug in the implementation, this did not work in the case of JEXL script files - every ${runscript.jexl(...)} call required the script text to be read and compiled. This has been fixed (performance improvement).

Secure Login Service Release 4.26.0 2013-04-15

JEXL / Groovy Functions

  • New: Functions cache.* that allow to create caches and to store objects in them. Intended for global caches (not for caching data per user/session). Sample use case: For SMS authentication a service has to be called to obtain an IP which can change every 60 minutes; using a cache, this IP can be stored and automatically expires and can then be obtained again. See the "JEXL Guide" for descriptions of the new functions.

SAML 2.0 Identity Provider

  • New: Support for displaying a SP selection page at login and support for displaying links for re-login in the Single Logout information page:

    New setting idp.sp.<no>.url that allows to specify the URL at the SP for the client browser to initiate a SAML login at the SP, plus corresponding new JEXL/Groovy functions idp.getSamlMessageIssuerSpUrl() and getSpUrl(aliasOrEntityId).

    New JEXL/Groovy function idp.getSpInfos() that returns an array of SP info (one entry per configured SP) with getters for EntityID, Alias and URL. Similarly, the SLO result array returned by idp.getSloResults() now has an additional getter for the SP URL.

    New JEXL/Groovy function isKnownSp(aliasOrEntityId), which returns true if the given SP alias or EntityID is a known (configured) SP.

    See the "SLS Administration Guide", "JEXL Guide" and sample configuration for more details.

SAML 2.0 Service Provider

  • New: The OIOSAML SP now supports HTTP proxy servers for outgoing connections when using the Artifact profile. See "SLS Administration Guide", chapter "SAML 2 Service Provider".

Various Fixes

  • Fixed: The LDAP adapter did not build the correct Distinguished Name (DN) for an object found in a filter search under some circumstances.

  • Fixed: The JEXL function response.sendBasicAuthRequiredHeaders() was supposed to automatically enable the processing of an "authorization" header in the subsequent request, even if basic auth was globally disabled. This didn't work correctly yet, and has been fixed in this release.

Secure Login Service Release 4.25.0.2 2014-05-05

  • New: Due to the way JEXL handles variable name resolution, it is possible that name collisions occur if a variable has the same name as a part of the name of another variable, i.e. mail would potentially collide with attribute.ldap.mail. As a result, in a case like this, an expression like ${attribute.ldap.mail} would return the value of the variable mail instead of attribute.ldap.mail. However, as a simple workaround, the function ${function.getVariable('attribute.ldap.mail')} could be used, which does not suffer from the same issue.

    In order to help avoiding this issue, potential name collisions like this are now detected automatically when a variable is created, and a corresponding WARN message is logged.

Secure Login Service Release 4.25.0.1 2014-04-30

RSA Adapter Update

  • Update: The RSA adapter has been updated with the libraries of version 8.1.1, in order to ensure compatibility with newer RSA ACE server versions.

LDAP Adapter

  • New: The LDAP adapter now supports Microsoft Active Directory password changes. While it was already possible to change a user password in an Active Directory, the modify operation used to do this was really an administrator operation in the context of an AD. Depending on the setup, this operation was not possible if the user's credentials were used to perform it, instead of administrator (tech) user credentials. Now, a new configuration property ldap.changepassword.isAD allows to define if the LDAP server is an Active Directory. If yes, the LDAP adapter will not perform a simple modify, but instead an LDAP request with a "delete" and an "add" operation, as specified by Microsoft. See "SLS Administration Guide", chapter "LDAP Adapter", for details.

  • Changed: It is now possible to specify an attribute value for an attribute "delete" operation. Usually, this is not necessary (obviously), but some LDAP backends need to use a delete operation with a specific marker value as part of a password change process.

  • Fixed: Under certain circumstances, the LDAP adapter would create an invalid Distinguished Name value in the variable ldap.search.dn for an object that was found in a filtered search. This has been fixed, so that the complete DN is now always correct.

Various Fixes And Improvements

  • Fixed: The JEXL function session.setRequestedPage() introduced a bug in the last release, when support for fully qualified URLs in the do.redirect state was introduced. As a result of the bug, the do.redirect state would ignore the URL-"property" completely, as soon as the JEXL function session.setRequestedPage() had been invoked. This has been fixed now, so that the do.redirect state will still use the corresponding URL from the "property", if one is supplied.

  • Fixed: There was a NullPointerException in the NTLM adapter in a situation where multiple authentication adapters were used, and the NTLM adapter was not the first one. So, when the model did not contain a state named do.ntlmauth, but (for example) do.ntlmauth3, the exception would occur. This has been fixed, so that all variants of the do.ntlmauth state can be used.

Secure Login Service Release 4.25.0 2013-03-25

Custom Log Messages

  • New: It is now possible to both create new, custom log messages, as well as override the text, severity and category of the existing ones. This can be used to change the text of log messages (such as USER_AUTH_SUCCESS) in order to adapt them for the needs of a particular log parser / monitoring tool. See the chapter "Custom Log Messages" in the "SLS Administration Guide" for more info.

JEXL / Groovy Functions

  • New: Functions session.mustChangePassword() and session.setPasswordChangeRequired() allow to check if a password change is required in the current session, or to mark the session to require a password change.

Various Fixes And Changes

  • New: Optimized performance of Groovy expressions and scripts.

  • New: New configuration property to avoid infinite loops in Groovy scripts: groovy.script.timeout.secs; default is 120 seconds (2 minutes). If a script runs longer than the timeout, it fails with a JEXL runtime exception.

Secure Login Service Release 4.24.0 2013-02-03

SLS Core

  • Support for Groovy in SLS : Generally everywhere where JEXL 2 script expressions can be used with ${...}, now also Groovy script expressions can be used with #{...}, i.e. using the pound sign instead of the dollar sign. This applies to configuration properties including login model actions, as well as to tags like getJexl in JSPs.

    To execute a Groovy script, use the new ${runscript.groovy()} functions, similar to the existing ${runscript.jexl()} functions.

    Groovy is a modern script language with features and a power of expression similar to Python and Ruby. Its syntax is often identical to JEXL in simple cases. More generally, almost every Java source code is syntactically valid Groovy, although many things can also be written much less verbosely in Groovy. Hence learning Groovy in the context of SLS configuration should be quite easy for anyone familiar with syntactically similar languages like JavaScript, Java, JEXL, C#, C, etc.

    See the chapter "Groovy Scripting" in the "SLS Administration Guide" for more info.

LDAP Adapter

  • Fix: The do.changepassword action would in some cases incorrectly not use the JEXL variable ldap.search.dn from a previous lookup and for this action the variable had incorrectly precedence over an explicitly configured search DN.
  • Fix: The do.auth action would in some cases produces an error 500 if the JEXL variable ldap.search.dn had never been set.
  • Fix: The JEXL variable ldap.search.dn now consistently contains the result of the last successful search, it is never reset.

SAML 2.0 Identity Provider

  • New: Support for multiple attribute values in assertion attributes and support for the X500/LDAP attribute profile besides the basic profile. See see the "SLS Administration Guide" and the SLS "JEXL Functions" guide for details.
  • New: For each SP an alias can be defined using the new configuration property idp.sp.<no>.alias and used in login models using the new JEXL function String idp.getSamlMessageIssuerAlias(). Defaults to the EntityID if no alias has been defined.

SAML 2.0 Service Provider

  • New: New setting oiosaml-sp.logoutresponse.redirect.metarefresh to send the LogoutResponse message during a Single Logout with a meta refresh tag instead of a normal HTTP 302 redirect. This helps to reduce the number of redirects during a logout involving several SPs, which might otherwise hit a browser limit (e.g. IE).

  • Fix: Single Logout now works if the SES session check feature is activated (OIOSAML SP property oiosaml-sp.enable.ses.session.check=true).

  • Fix: Removed inappropriate warn log entries at Single Logout.

New JEXL Functions

  • New: JEXL functions for handling multiple string credentials identified by their name. All new functions are session. functions and contain the string StringCred in their names, e.g. session.getStringCred().

  • New: JEXL function session.getFullModelState() returns the name of the current model state including the extension (if it has one), e.g. do.generic-checkUp instead of just do.generic.

Various Fixes And Changes

  • Fix: The "do.redirect" state did not check absolute URLs against any white- or blacklists. Now, all redirect URLs (no matter if configured in the param.url state parameter or coming from the target or the requestedPage parameters) will be checked against the whitelist and blacklist for the requested page (i.e., the properties requested.page.whitelist and requested.page.blacklist).

  • Fix: <script> tags in JSPs have been converted to a form that is valid xhtml (typ. <script type="text/javascript">).

  • Fix: JEXL functions for array handling.

  • Fix: A missing ".name"-suffix in a model state name resulted in a runtime exception instead of a proper configuration error with a helpful message. Now the erronuous property is pointed out by the error message.

Secure Login Service Release 4.23.0 2013-12-04

SAML 2.0 Service Provider

  • New: New configuration properties that allow to customize the content of the AuthnRequest: oiosaml-sp.authnrequest.providername, oiosaml-sp.authnrequest.authncontext.comparison and oiosaml-sp.authnrequest.authncontext.classrefs. See see the "SLS Administration Guide" for usage.

Various Fixes And Changes

  • Fix: The OIOSAML SP filter threw a NullPointerException at SLS startup time when it was configured in the web.xml, but no oiosaml-conf subdirectory existed. Even if it was disabled. This has been fixed, so that if the filter is disabled, a missing configuration directory is not an issue anymore.

  • Fix: No longer truncates RequestedPage URL if it contains the string "req".

  • Fix: If already.loggedin.page is true and a model is created by a missing authorization, the model is now correctly triggered instead of showing the already-logged-in page.

  • New: If already.loggedin.page is true and there are missing authorizations for which no model is defined, an appropriate message can be shown to the user in the already-logged-in page by querying if the new special JEXL variable special.authorizations.missing is true.

  • Fix: Fixed a minor issue with parsing session attribute headers.

Secure Login Service Release 4.22.1 2013-11-19

Tomcat Authenticator

  • New: Support for Tomcat 7. There are now two SES Tomcat Authenticator JARs, one for Tomcat 5.5 and 6 and one for Tomcat 7. This has become necessary because the Tomcat Authenticator Java API has been slightly changed in Tomcat 7. Configuration remains practically the same, as well as most files and how to install, see the "SLS Administration Guide" for details.

SAML 2.0 Identity Provider

  • Fix in documentation: Only USERNAME and TOKENSELECTION credentials are restored automatically from the user info cookie during a SAML SSO login; store further credential values explicitly if needed.

Secure Login Service Release 4.22.0 2013-10-28

Java 5 no longer supported

  • Support for Java 5 has been stopped, for various reasons; among them the fact that several 3rd-party libraries and components in the SLS now require Java 6 or newer. The core SLS and most of its components are still compiled for Java 5 and may or may not run with a Java 5 runtime, depending on what functionality is used, but official support for Java 5 has ceased. SLS releases are tested with Java 6.

SLS Core

  • Experimental support for Groovy in SLS : Generally everywhere where JEXL 2 script expressions can be used with ${...} now also Groovy script expressions can be used with #{...}, i.e. using the pound sign instead of the dollar sign. This applies to configuration properties including login model actions, as well as to tags like getJexl in JSPs.

    To execute a Groovy script, use the new ${runscript.groovy()} functions, similar to the existing ${runscript.jexl()} functions.

    Groovy is a modern script language with features and a power of expression similar to Python and Ruby. Its syntax is often identical to JEXL in simple cases. More generally, almost every Java source code is syntactically valid Groovy, although many things can also be written much less verbosely in Groovy. Hence learning Groovy in the context of SLS configuration should be quite easy for anyone familiar with syntactically similar languages like JavaScript, Java, JEXL, C#, C, etc.

    Please be aware that this feature is experimental: If you use it, backwards compatibility with future SLS versions is not guaranteed, yet, although this is already essentially aimed for.

  • Fixed: Whenever the SLS requests basic authentication, it will process incoming credentials in the next request. Previously, if basic authentication was globally disabled, and the JEXL function response.setBasicAuthRequiredHeaders() was used, the basic authentication credentials in the following request were ignored (due to the globally disabled basic auth). Also, the following GET request will now automatically be processed like a POST request; therefore, using the JEXL function session.processNextGETasPOST() is not necessary anymore for this case.

SAML 2.0 Service Provider

  • New: There is a new commandline tool (an executable jar file) that allows to create configuration files for the OIOSAML service provider offline - no need to have an SLS instance up and running first. See "SLS Administration Guide", chapter "32.5 OIOSAML Configuration Tool" for details.

SAML 2.0 Identity Provider

  • New: New JEXL function idp.isReauthentication() to optionally allow to enforce reauthentication at the SAML IdP if the AuthnRequest is from an SP which has already been authenticated at the IdP, i.e. AuthnRequest to IdP has probably been initiated by an inactivity timeout at the SP.

  • New: The block cipher to use for encrypting the SAML Assertion is now configurable, property idp.sp.<no>.blockcipher, see "SLS Administration Guide" for details.

  • New: SAML IdP logins are now compatible with with the do.completeauth model action: The SAML credential is removed in the saml handle message action (and its items are remembered in the internal SAML context).

  • Fix: The SessionIndex in the Assertion is set to the Assertion ID, in accordance with the SAML 2.0 standard, instead of previously being randomly generated.

  • Fix: Session attributes to the HSP that are base64 encoded are no longer first encoded using the platform default encoding but with UTF-8, as it is already the case with URL encoded session attributes.

HTTP Adapter

  • Fix: Correctly supports aliases that contain a dot, e.g. http.mywsdl.wsdl_getData.url=....

  • Fix: Correctly splits comma separated backend URLs configured in HTTP adapter when the URLs contains JEXL expressions which contain commas; affects settings http.auth.url and http.<alias>.url.

LDAP Adapter

  • New: Default LDAP read timeout com.sun.jndi.ldap.read.timeout of 1 minute; previously not set by default which resulted in no timeout.

Various Fixes And Changes

  • New: Two new JEXL functions for XML encoding and decoding, namely function.xmlEncode(String) and function.xmlDecode(String).

  • Fix: Fixed a bug that prevented SAML IdP SSO if e.g. the RelayState contained characters like = or !.

Secure Login Service Release 4.21.0.1 2013-11-14

  • Fixed: The LDAP adapter did not handle multi-value-attributes without any value (size == 0) correctly, which resulted in a runtime exception. This has been fixed, so that attributes like that will be handled like empty string-attributes.

Secure Login Service Release 4.21.0 2013-09-24

  • New: The LDAP adapter now supports naming attributes to be returned in searches, such as the optional authentication search, mapping search and custom operation searches. This is also important in order to access so-called "operational" attributes in an OpenLDAP directory. See "SLS Administration Guide", chapter "LDAP Adapter" / "Search for Named Attributes".

Secure Login Service Release 4.20.2 2013-09-18

  • Update: The JEXL function session.setRequestedPage() now also allows to set a fully qualified URL with an external hostname. While the regular "requestedPage" will still be subject to hostname restrictions, the URL given with this function can be absolute, since it does not provide any means for a client to influence the target of the final redirect (while the regular "requestedPage" or "target" parameters could be manipulated under certain conditions).

Secure Login Service Release 4.20.1 2013-09-11

Various Fixes And Changes

  • Fix: The SAML SP now correctly reauthenticates via SAML/IdP when the HSP redirects to the SLS after expiry of the HSP settings AC_HspCredentialValidityPeriod or AC_HspCredentialFinalTimeout.

Secure Login Service Release 4.20.0 2013-09-06

Various Fixes And Changes

  • Fix/Feature: A bug has been fixed that could cause login models to be reset in the middle if autorizations are required; especially setting authorizations was in many cases effectively not not supported for the root location of a virtual host. This change works with practially any HSP version. For HSP 4.5.0 only, however, due to a bug, the following setting, which is only supported in HSP 4.5.0, must be defined: AC_IgnoreSlsLoginCookie On. See the FAQ section of the "SLS Administration Guide" for more details.

  • Fix: The SAML IdP now correctly sets AccessArea response headers to the HSP. Previous versions did not set this header, which means that technically the user was not logged in at the IdP. No impact on security, only so that timeouts of an anonymous session apply for SAML SSO at the IdP in previous versions of SLS.

Secure Login Service Release 4.19.0.2 2013-10-04

HTTP Adapter

  • Fix: Correctly supports aliases that contain a dot, e.g. http.mywsdl.wsdl_getData.url=....

Secure Login Service Release 4.19.0.1 2013-10-01

HTTP Adapter

  • Fix: Correctly splits comma separated backend URLs configured in HTTP adapter when the URLs contains JEXL expressions which contain commas; affects settings http.auth.url and http.<alias>.url.

Secure Login Service Release 4.19.0-SP3 2013-08-26

  • Fix: Classpath build errors fixed.

Secure Login Service Release 4.19.0-SP2 2013-08-20

Various Fixes And Changes

  • Fix: Bug in OIOSAML SP configuration handling which prevented proper initial configuration setup using the OIOSAML web frontend.

Secure Login Service Release 4.19.0 2013-08-15

Various Fixes And Changes

  • Fix/Feature: New action parameter for do.redirect action: url.absolute.allow. If set to true, an absolute URL given in action property or url action parameter is used and not forced to the same host as where the SLS was accessed; default is false for backwards compatibility.

  • Fix: Due to the way the OIOSAML Service Provider handled its configuration, there was a problem when using multiple SLS Service Providers within the same server. With this fix, having multiple web apps in the same servlet container, each acting as a different SAML Service Provider is not a problem anymore.

  • Fix: The SLSLogin cookie is currently not added automatically any more (the implementation in 4.18.0 is not working correctly). As a workaround, set the SLSLogin cookie in the model in the rare cases where this is needed, see FAQ section of the "SLS Administration Guide" for details. [Added 2013-08-26: The workaround described above does not work, the issue has been resolved differently in SLS 4.20.0, see there.]

Secure Login Service Release 4.18.0 2013-08-08

SAML Service Provider Features

  • New: The SAML Service Provider now creates a number of JEXL variables, all prefixed with assertion.. All user attributes are represented by JEXL variables named assertion.attribute.<friendly name>, while there are also several other fixed variables for attributes such as common name, issuer etc. See "SLS Administration Guide", chapter 27.6.7 for details.

SAML Identity Provider Features

  • New: SAML Assertions can optionally be encrypted to protect confidential Attributes in the assertion. Use the new setting idp.sp.<no>.assertion.encrypt to activate encrypting assertions for messages to the respective SP (see "SLS Administration Guide" for details).

Various Fixes And Changes

  • Fix: The SAML IdP configuration property idp.assertion.validity.secs was mistakenly defined as a dynamic property, now it is a normal (static) property.

  • Fix/Feature: The SLS now sets a new Cookie to the HSP, called "SLSLogin" and with value ongoing. This cookie is set with each response to the HSP if the SLS login session is still open and it is deleted with each response to the HSP if the SLS login session is terminated. This allows (in combination with a HSP that knows about the new cookie) to avoid issues that login models rarely have in combination with authorizations, especially if authorizations have been set for the root (/) location. See FAQ section of the "SLS Administration Guide" for details. [Added 2013-08-26: The issue has been resolved differently, without a new cookie, in SLS 4.20.0, see there.]

Secure Login Service Release 4.17.0 2013-07-11

SAML Identity Provider Features

  • New: Flexible definition of attributes to put into the SAML Assertion. Attributes can be set individually per SP in the login model and, using JEXL script files as templates, they can be managed flexibly in the model.
  • New: JEXL function idp.setAssertionAttribute(type, friendlyName, name, value) for setting attributes in the model.

OIOSAML Service Provider Update

  • Change: In case of an error, the service provider will not show a stacktrace anymore, just the error message.

Secure Login Service Release 4.16.0 2013-06-11

SAML Identity Provider Features

  • New: JEXL functions for the SAML 2.0 Identity Provider (IdP) to cover e.g. the use case where a user bookmarks the login location at the IdP, including an AuthnRequest with Redirect Binding as a URL parameter.
  • boolean idp.hasSamlMessage(): Whether the IdP has received a SAML message or not.
  • int idp.getSamlMessageMaxAgeSecs(): Age in seconds of the SAML message.
  • String idp.getSamlMessageIssuer(): Issuer (EntityID) of the SAML message.

See "JEXL Guide" for more details about these functions and see "SLS Administration Guide" for usage samples in login models.

OIOSAML Service Provider Logging Improvement

  • New: The OIOSAML Service Provider in the SLS can now be configured with appender and logger entries in the standard SLS Log4j configuration file (WEB-INF/log4j.xml), in which case the old OIOSAML-specific Log4j configuration file will be ignored. This simplifies logging configuration due to not having to maintain two configuration files, and also allows to simply merge the OIOSAML and SLS audit logs (debug logs should remain separated because they can contain stacktraces). Also, the logs can contain client- and request-correlator values like all other SLS log files, allowing for easier correlation of log records. See "SLS Administration Guide", chapter "Logging" for details.

HTTP Adapter Failover Support

  • New: The HTTP adapter now supports simple round-robin failover, just by adding additional URLs, separated by commas, to any URL configuration property.

File Adapter Challenge-/Response Support

  • The File adapter, used only for testing purposes, did not properly support a challenge-/response flow, using the "basechallenge" adapter, and the model states "create.challenge" and "do.authresponse". This has been fixed, so that this adapter can also be used to test challenge-/response flows.

Various Fixes And Changes

  • Fix / Change: Dynamic parts of LDAP configuration properties such as filters and DNs were not escaped by the adapter itself so far. Escaping or blocking of potentially dangerous characters had to be enforced through the HSP or SLS parameter checker. The LDAP adapter now implements an escaping of dynamic (JEXL) values in DN and filter configuration properties. In the software, this new behaviour must be enabled by setting the new configuration property ldap.enable.escaping to true; in the appliance, it is enabled by default for new installations.

  • Fix / Change: If multiple errors occur during one request processed by the SLS, the first error was displayed in the login page (instead of the last one, which would probably be the expected behaviour in most cases). For reasons of backwards compatibility, the default behaviour is still the same, but by setting the new configuration property jsp.globalerror.last to true, it can be changed so that the last error will instead be shown in the page.

  • Change: The shutdown handling has been improved, to reduce misleading and invalid container error messages about supposed potential memory leaks etc.

  • Fixed: A thread leak in the SAML Identity Provider (IdP) which created a new running java.util.Timer instance per new SLS Login Session.

Secure Login Service Release 4.15.0 2013-04-30

Application-URI-based language selection

  • New: The language of the SLS session can now also be selected based on the URI of the requested page (application). Either through matching a substring with a regular expression defined by the new property lang.uri.regex, or by defining the index number of the URI part which represents the language code with the new property lang.uri.part.no. See "SLS Administration Guide", chapter "Selecting User Language" for details.

New JEXL functions

  • New: JEXL functions getSlsClientErrorMessageKey() and getSlsClientErrorMessage() provide access to the localized error message as it would be rendered in the JSP do be displayed for the end-user. See "JEXL Guide" for details.

New HTML documentation for JEXL and Taglib

  • New: HTML versions of the "JEXL Guide" and the "JSP Taglib Guide" are now available in addition to the PDF documentation.

JEXL variables documentation improved

  • The list of available JEXL variables in the "JEXL" chapter of the "SLS Administration Guide" has been improved and lists now all variables that are available at runtime.

Various fixes

  • Change: The threshold which triggers an INFINITE LOOP DETECTED error if too many internal forwards are performed has been increased from 30 to 300. In addition, it can now be configured using the new, optional configuration property infinite.loop.threshold.

  • Fixed: A bug in the USP custom Log4j logger which sometimes prevented proper logging of Java method names on TRACE log level.

  • Fixed: A bug in the back-end monitoring mechanism required custom principal credentials for custom LDAP operations to be configured twice (e.g. ldap.principal.userlookup and ldap.principal.userlookup-search). This has been fixed, so that the second configuration entry is not necessary anymore.

Secure Login Service Release 4.14.3 2013-03-07

Interoperability of SuisseID and IdP Adapter on same SLS

  • Fixed: A bug was fixed which prevented the SuisseID and IdP adapter to be used together on the same SLS instance.

Secure Login Service Release 4.14.2 2013-03-06

OIOSAML Service Provider Bugfix

  • Fixed: A newly introduced patch in the OIOSAML SP also added a potential error when setting up a new OIOSAML instance. This has been fixed, so the OIOSAML self-configuration JSP works again correctly.

Secure Login Service Release 4.14.1 2013-03-01

HTTP Adapter SSL Bugfix

  • Fixed: The upgrade of the "Apache HttpClient" API used by the HTTP adapter resulted in a problem with HTTPS connections that required mutual authentication.

Secure Login Service Release 4.14.0 2013-02-11

HTTP Adapter SPNEGO support

  • New: The HTTP adapter now also supports SPNEGO for authentication against the target backend or a proxy server (requires additional Kerberos- and JAAS- configuration and a keytab file - see "SLS Administration Guide", "HTTP Adapter" for details).

SAML 2.0 Identity Provider with Single Logout

  • New: The SAML 2.0 Identity Provider (IdP) now supports Single Logout: Sequentially performs SAML logout to all Service Providers (SPs) where the user was logged in (IdP initiatated, with Redirect Binding). See Admin Guide (section "SAML IdP Adapter") for a detailed feature description.

  • New/Fixed: Support AuthnRequests without AssertionConsumerServiceURL attribute and without ProtocolBinding attribute (in that case uses the location of the AssertionConsumerService for POST binding in the SP metadata).

New Tags in the SLS Tag Library

  • New: Tag whileJexl similar to the existing ifJexl tag, with the difference that the tag body is executed repeatedly as long as the condition remains true. Can, for example, be used to iterate over a list or an array in a JSP.

  • New: Tag logoutHsp that logs out a user from the current or all sessions by invalidating the HSP session.

OIOSAML Log4j Extension

  • New: The OIOSAML Service Provider included in the SLS now also supports the same Log4j variables for the RequestCorrelator and ClientCorrelator request headers as the SLS. So, by adding the fields [CC:%X{cc}] [RC:%X{rc}] to the conversion patterns in the OIOSAML log4j configuration, the log records in these files can now also be properly correlated with all other HSP and SLS logs.

URL Encoding

  • Fixed: Some URL encoding issues that show primarily with the do.redirect action have been fixed.

Tenant-specific Logging

  • Fixed: A bug in the handling of the internal default tenant (used when multi-tenancy is enabled, but no tenant could be resolved) lead to potientially missing log records, if no logger was configured for a default tenant.

Secure Login Service Release 4.13.1 2013-01-10

JEXL HmacSHA1 Hashing

  • New: The JEXL function function.getHmacSha1() allows to create a HMAC-SHA1 hash based on a shared secret. See JEXL Guide for details.

HTTP Adapter Improvements

  • New: The HTTP adapter now supports using a HTTP proxy server for all HTTP calls. It also supports authenticating proxy servers with basic and NTLM authentication. (see "SLS Administration Guide", chapter "HTTP Adapter" / "Proxy Support" for details).

  • New: The HTTP adapter now supports Basic and NTLM authentication towards the target HTTP back-end system (see "SLS Administration Guide", chapter "HTTP Adapter" / "Backend Authentication Realms" for details).

  • New: The HTTP adapter now allows to configure a custom timeout threshold for all HTTP connections. It defaults to 1 minute if not set (see "SLS Administration Guide", chapter "HTTP Adapter" / "Connection Timeout" for details).

  • New: The HTTP adapter now allows to configure custom verification of the common name in the SSL peer certificate in HTTPS connections. Also, optionally, a check of the connection DNS name can be enforced.

  • New: The HTTP adapter now creates a JEXL variable http.response.code after each HTTP call, which stores the HTTP response code.

Secure Login Service Release 4.13.0 2012-12-10

SAML 2.0 Identity Provider with Single Sign On

  • New: The SAML 2.0 Identity Provider (IdP) now supports Single Sign On (SSO), i.e. login from different SAML Service Providers (SPs) such that the user only has to present credentials once at the first login via an SP. Generally, the IdP supports so far SAML login initiated by SP with Redirect/POST bindings. See Admin Guide (section "SAML IdP Adapter") for a detailed feature description.

UTF-8 Support

  • New: The SLS now sets the content-type of responses (HTML from JSPs) automatically to UTF-8, and processes content posted from its form as UTF-8 as well. This eliminates most issues with passwords or usernames with special characters, such as german umlauts etc. It also eliminates the need for any special configuration of the Tomcat used to run the SLS, as well as any changes in the SLS JSPs.

New JEXL function "function.getValueFromFile()"

  • New: A JEXL function that yields the first non-comment line of the indicated file. Useful, for example, for getting a property from a file, e.g. a password. Example: some.password=${function.getValueFromFile('/path/to/file/with/password')}.

New JEXL functions "response.propagateBasicAuthHeaderToApp()"

  • New: Two additional variants of the JEXL function response.propagateBasicAuthHeaderToApp() has been added, which require either only a path argument or no input arguments at all. They automatically use the user credentials from the current login session (which means that the username and password credentials must exist and be verified, or an exception will be thrown).

New JEXL functions "function.isArray()"

  • New: A set of JEXL functions has been added which allow to check if a given JEXL variable is actually an array. Multiple variants of this function were implemented to support arrays of type Object[] as well as various native types (byte[], int[], float[] and long[]). So by using function.isArray(myVars), it's easy to determine if an iteration over the array elements with foreach(myVar in myVars) is possible / necessary or not.

New JEXL variable for certificate in PKI login

  • New: The new JEXL variable special.certificate is set by the PKI adapter after a successful authentication. It contains a Java object of the type java.security.cert.X509Certificate and provides access to all methods of that Java class, so that all information of that certificate is available to be used in custom validations, conditions etc.

Verified "username" credential in model trigger

  • Fixed: When an already authenticated user returns to the SLS, the user ID should be available in the SLS as a verified username credential, because the SLS creates a protected cookie with the username after a successful login (that cookie is NOT persistent and lives only as long as the SES session). However, the processing of this cookie was too late; it happened after the model triggers were already processed. So, using a model with a conditional (if) trigger with the JEXL function session.getVerifiedCred('username') did not work as expected, even though that same function worked perfectly afterwards within the model. This has been fixed, so that model triggers can use this function (and session.isAuthenticated()) in JEXL model triggers.

Check for "Unlimited Jurisdiction Strength Policy" files in JVM

  • New: The SLS performs a check at startup time to ensure that strong cryptography is available. If this check fails, it means that the Java VM used to run the SLS had not been properly instrumented with the "Unlimited Jurisdiction Policy Strength" files.

Check for change of "requested page"

  • New: In case the requested page changes during a login session, the SLS will restart the login from scratch, clearing all credentials from the current session. This check helps avoiding some potential security issues that may arise if one single login model is used to handle login procedures for different authentication levels (access area Member and Customer), and doesn't properly deal with all possible user interaction flows in the model. In case this is a problem, the check can be disabled with the new configuration property disable.requested.page.check=false (see "SLS Administration Guide" for details).

Model validation improvements

  • New: Previously, when the JEXL expression in a model action was not enclosed in the ${ and } characters, it was not interpreted at all, but silently ignored. While this behaviour is correct for most configuration properties (because they usually have fixed values by default), in this particular case the value of the property cannot contain anything else than a JEXL expression, so it should always be evaluated as one. This has been fixed, so that even an action without the proper prefix and brackets around it will be interpreted by the JEXL engine.

    IMPORTANT NOTE: This new feature may impact some existing models where previously a state that was never reached was necessary in the model. Since that invalid state was never actually reached, no error ever occurred - this now different because of the new startup check. The most common example is the following logout model:

    model.logoutcmd.uri=/logout model.logoutcmd.failedState=get.usererror model.logoutcmd.state.1.name=do.logout model.logoutcmd.state.1.nextState=3 model.logoutcmd.state.2.name=get.usererror model.logoutcmd.state.3.name=completed

    This has to be changed to the following (i.e. remove state 3):

    model.logoutcmd.uri=/logout model.logoutcmd.failedState=get.usererror model.logoutcmd.state.1.name=do.logout model.logoutcmd.state.2.name=get.usererror

  • New: If a model state name accidentally contained a JEXL expression instead of an actual name, such as model.login.state.10.name=${myvariable}, it was silently ignored by the model validation. This will now trigger an SLS startup error (model states must always be fixed values).

"Application logout" audit log message

  • New: When the SLS performs a do.applogout state (which redirects to a logout location of the application), an audit log message with the ID USER_APP_LOGOUT is written.

Secure Login Service Release 4.12.0 2012-10-25

  • New: SAML 2.0 Identity Provider (IdP). Supports SAML login initiated by a SAML Service Provider (SP) with Redirect/POST bindings, but so far without SSO, yet. See Admin Guide (section "SAML IdP Adapter") for a detailed feature description.

Secure Login Service Release 4.11.8-SP2 2012-10-08

  • Fixed: Priority of model triggers was broken; JEXL-triggers had higher priority than the missingAuthorization-Trigger, due to an internal error, which was silently swallowed.

Secure Login Service Release 4.11.7 2012-07-30

  • Fixed: A bug in the SHS library prevented the SLS from restarting the login model after a failed login attempt, without closing and re-opening the web browser. Now, a link with a cmd=auth parameter in the error page can restart the login model, allowing the user to select a different certificate for authentication, for example.

  • Fixed: A trace-log statement in the SLS session handling accidentally logged password values. Those values are now filtered and replaced with a "hidden" label.

Secure Login Service Release 4.11.6 2012-07-18

  • Fixed: The USP-proprietary "Secure Handshake" (SHS) functionality did not support TLS 1.2 up until now, also due to limitations of the SHS library in the SLS framework. This has been fixed, TLS 1.2 clients are supported now.

Secure Login Service Release 4.11.5 2012-05-30

  • Improved: The do.sendmail state now additionally supports the configuration property ...mimeType for each configured mail, so that mails can also have a different MIME type than text/plain.

  • New: JEXL function function.sendMail(String, String, String, String, String) allows to send a mail and specify its MIME type. The existing function always used text/plain.

  • New: Parameter aliases allow to define 1-n aliases for any well-known SLS parameter, such as target, requestedPage, cmd etc. To define an alias for such an existing parameter, a configuration property parameter.alias.<name/>=alias[,alias2,alias3...] can be set, where .name is the name of the existing parameter, and the value of the property consists of 1 - n alias names (comma-separated). See "SLS Administration Guide", chapter 10.1 "Parameter Aliases" for details.

  • Fixed: The tenant-specific logging did not work for the "default" tenant in several cases, for instance audit logs of successful or failed login attempts. In such cases, no log records were written at all, because the name of the logger was resovled in an invalid way internally. This has been fixed, so now all such log records will be written to their corresponding, non-tenant-specific file correctly.

  • Fixed: A memory consumption optimization in release 4.11.1, meant to improve stability in some cases of technical errors, also had unwanted side effects on custom error handling in the model, using custom failed states. Because in such cases the SLS session had been invalidated, any custom JEXL actions intended to create / change credentials etc. would not work anymore. This has been fixed, so that such models will work again as they did with previous releases.

Secure Login Service Release 4.11.4 2012-05-14

  • New: JEXL function session.isAuthenticated() allows to check if the current HSP session is authenticated (a valid username credential exists, and the CredentialState field of the SessionInfo header is Valid).

  • New: JEXL function getMissingAuthorizations() (without a second parameter) allows to retrieve the list of missing authorization values.

Secure Login Service Release 4.11.2 2012-05-11

  • New: The optional HTML input element attribute placeholder (since HTML 5) is now supported by the sls:inputField JSP tag.

  • Fixed: Tomcat 7 compatibility has been implemented through both a fix in the web.xml file, some of the tag-lib descriptors (.tld) and the controller servlet code.

  • Fixed: The JSP tag sls:form takes an attribute action which is usually set to auth. In cases where there are multiple models in an SLS, triggered by different URIs (one by /auth and the other one by, say, /secure), and the same JSP was used in both models (with the get.cred state), it would break the model /secure. Because the POST would always go to /auth, and thereby trigger the start of the corresponding model. Now, the JSP tag sls:form will always take the current session model into account when rendering the action attribute, and if the current model was triggered by an URI, the POST action will go to the same URI as well.

  • New: Together with the fix in the sls:form tag concerning the action attribute, the new attribute forceAction has been introduced. It can be used instead of the action attribute, and if it is set, its value will be used as the action URI in the form, no matter what the current model trigger URI was.

Secure Login Service Release 4.11.1 2012-04-13

  • New: JEXL variables are created for each actively used back-end authentication system. The variable names begin with the back-end type, such as ldap, followed by .current.backend, e.g. ldap.current.backend=192.168.13.10.

  • New: JEXL function function.base64toHex() converts a Base64 string to a hex string. This may be useful when dealing with Base64 strings created through the MD5- or SHA-X-functions, which create Base64 strings for historical reasons.

  • New: JEXL functions md5hex(), sha1hex(), sha256hex() and sha512hex() create the corresponding hashes, but as a hex string (and not as a base64 string like the existing functions).

  • Fixed: Setting a custom "host" request header in the HTTP adapter was not possible, due to the Apache httpclient library, which uses the hostname from the URL to set the host header automatically. This has been fixed now, so setting a custom host header will work as expected.

  • Improved: Memory usage has been optimized for a situation where the SLS cannot operate at all due to a complete back-end outage, while still receiving a large number of authentication requests at the same time (which would be typical for automated authentication protocols such as NTLM or Kerberos). This greatly reduces the potential for an OutOfMemoryError.

  • Fixed: If the LDAP adapter was configured for authentication, but neither a bind principal nor any bind DN prefixes were configured, the adapter would not show any error; the authentication just failed with a somewhat useless log message that "no authentication had been performed". Now, in this situation, a system error will occur, with an exception in the exception log, and an informative error message.

Secure Login Service Release 4.11.0 2012-02-13

  • New: NTLM-adapter now supports NTLMv2 authentication, which is especially important with Windows Vista / 7, where NTLMv2 is now enforced by default. Most of the configuration can remain unchanged, but the NTLM adapter properties have slightly changed. Most importantly, the account needed for the NETLOGON connection between the SLS and the domain controller needs to be a computer account now, not just a user account (see "SLS Administration Guide" for details).

  • Fixed: Broken SOAP frontend, caused by new jar files in the classpath.

  • New: JEXL-function session.setLanguage() allows to set the language code for the current session from within a model state action or JSP (see "JEXL Guide" for details).

Secure Login Service Release 4.10.1 2011-11-17

  • Fixed: Potential concurrency issue with some configuration properties whose values used JEXL expressions, e.g. app.header. In some cases, this could lead to information leaking from one user session to another. This bug was introduced in SLS release 4.8.6, so all SLS instances with versions ranging from 4.8.6 and later should be upgraded immediately.

  • New: SuisseID adapter allows to authenticate users with their personal SuisseID card, using SAML-based delegation to the Identity Provider who issued the ID. See "SLS Administration Guide", chapter "SuisseID Adapter".

  • New: Model state do.sendmail and JEXL functions function.sendMail() allow to send e-mails at any point of a login model. See "SLS Administration Guide", chapter "Sending eMail" for details.

  • New: JEXL-function function.registerClassPrefix(String, String) allows to create an instance of any Java class with a certain prefix, in order to be able to use its static methods (because JEXL doesn't really support static method call of any arbitrary class). This allows to use all the static APIs of java.lang.String, java.lang.Integer and all other useful Java core classes. See "SLS Administration Guide", chapter "Expressions" / "Static Method Calls".

  • New: JEXL-function function.logToLog4j allows to write any custom log message with any desired log level to any particular named logger. See "JEXL Functions" guide for details.

  • Improved: model validation now warns if orphaned states are found. These are states that only have an .action, .nextState or .failedState defined in the model, but no corresponding .name (a typical copy-paste error).

  • Improved: If a model should be triggered by a missing authorization, it was only created if there wasn't a model in the session yet. But if there was already one, the missing authorization did not trigger the creation of the corresponding model, which could cause problems in several use-cases where a user would potentially not complete the current login model, and access a location which required a different login model based on that locations authorization settings. Now, the SLS will always enforce the creation of a new model if the current request (usually the GET resulting from the redirect of the HSP) contains information about missing authorizations.

Secure Login Service Release 4.9.7 2011-08-25

  • New / Fixed: When multi-tenancy is used, separate log files can now be configured for each tenant. This is also a necessary fix in case the multi-tenancy uses URI path separation (instead of different hostnames). See "SLS Administration Guide", chapter 22.4 "Tenant-specific logging" for details.

  • Improved: The "performance.log" now contains the full name of a state, including the optional suffix, e.g. do.generic-FirstTry. This helps understanding the performance log in comples models better.

Secure Login Service Release 4.9.5 2011-07-12

  • Fixed: The Tomcat Authenticator could fail with a NullPointerException under certain circumstances, if a public (non-authenticated) request was processed.

  • Fixed: When a custom LDAP update operation had ignoreErrors set to false, errors were still ignored, if the global configuration property ldap.ignore.update.errors was not explicitely set to false as well. This has been fixed; now, the setting of the custom LDAP action always overrides the global configuration value.

  • New: The LDAP adapter now supports octet attribute type for the password change functionality (meaning when it's used with the do.changepassword model state). The new configuration property ldap.changepassword.isOctet can be set to true to enable this.

  • New: The URL parameter cmd=displayjsp can be used to let the SLS respond with the JSP defined by the second parameter jsp, which must contain the key of a JSP file in the message resource file (such as jsp.login). This is a special value for the cmd parameter, which does not require the existence of a corresponding model. The SLS will simply invoke the ShowJspAction directly, independent of the current session model and state.

  • Fixed: The challenge / response code validation did not implement the slowdown if multiple invalid response codes were entered.

  • Fixed: Due to an incorrect exception handling within the Axsionics adapter, all already verified credentials (such as username or password) were lost in a multi-step login procedure, if the token code was entered wrong during the first attempt. That lead to an internal error in the do.success step then, because those credentials were not marked as verified anymore.

Secure Login Service Release 4.9.4 2011-06-21

  • New: integration of custom key-value pair attributes in a customized principal for the SSO filters. All key-value pairs in the userdata header will be processed by the filter and stored in the principal. The application is able to cast the principal to IExtendedPrincipal and retrieve the attributes through the getValue(<key>) call.

Secure Login Service Release 4.9.3 2011-05-24

  • New: Tested and documented support for Yubikey USB tokens, using the HTTP adapter and Yubico's freely available verification cloud services. See "SLS Administration Guide", chapter "Yubikey Support", for details. Also, corresponding sample configurations have been included in the examples subdirectory of the SLS web application.

  • Fixed: GET HTTP calls for the HTTP-Adapter (when working as a generic HTTP adapter) were not working if they do not have a body.

  • New: the HTTP-Adapter supports now authentication using GET requests.

  • New: Support for Yubikey tokens through free Yubico authentication cloud tested and documented. Sample configurations have been added to show how to use the Yubikey USB token for strong authentication, in connection with the HTTP adapter of the SLS. See the sample configuration in the WEB-INF/examples directory of the SLS web application.

  • New: config property http.auth.header for the HTTP-Adapter. If neither deny - OK codes were configured nor OK body content, a response header (name and value) can be configured denoting a successfully authentication.

  • Fixed: Bugs in LDAP adapter that prevented proper use of various authentication setups. For example, using the ldap.auth.bind.dn.* prefixes without the ldap.auth.bind.principal wasn't really possible, even though the documentation said so. And the ldap.auth.search.* properties could be used only for an after-bind search, but not for looking up a user DN before binding. This has been fixed and improved, and the documentation in the "LDAP Adapter" chapter of the "SLS Administration Guide" has been fixed accordingly.

Secure Login Service Release 4.9.2 2011-05-05

  • New: JEXL function function.currentDate() returns the current time and date as a java.util.Date object.

  • New: Support for tenant-specific default language through the configuration property lang.default.<tenant/>=.

  • Fixed: Missing support for namespaces within XML data in all the function.xPath*() JEXL functions. Now, coding the namespace prefix of a node into the xPath-expression will find the corresponding node.

  • Fixed: Bug in JEXL date formatting function could lead to runtime errors due to multithreading concurrency issues.

  • Update: Upgraded DataProtector tool and library to version 2.5.5, which has been re-compiled for Java 1.3 compatibility, and supports the IBM JCE provider available in IBM JVMs natively, in addition to the support for the existing JCE providers.

  • Fixed: Various bugs in the OIOSAML SAML service provider, in order to improve the SAML 2.0 compatibility / compliance.

Secure Login Service Release 4.9.1 2011-03-29

  • New: JEXL function session.markCredAsVerified() allows to mark an existing credential as verified, so that the do.success model state will be satisfied by it. This can be used in special cases to implement an authentication within the model, without using an actual authentication back-end adapter. See "JEXL Guide" for details.

  • Fixed: File adapter now supports the do.mapping model state. It creates a MAPPEDID credential with the value of the user attribute mappedid, if it exists. Otherwise, the value of the USERNAME credential will be used.

Secure Login Service Release 4.9.0 2011-03-23

  • Improved HTTP adapter documentation in SLS Administration Guide.

  • New: JEXL functions for parsing XML data with xPath expressions. See JEXL Guide for details.

  • New: JEXL function samlsp.sendAttributeQuery() which allows to send an attribute query to the IdP.

  • New: WSDL Commandline Tool allows to create XML data files that can be used as input (through the JEXL template mechanism) for POST requests sent with the HTTP adapter. This allows to send SOAP requests from the SLS to a back-end web service, while the new xPath JEXL functions provide the means to process the response.

Secure Login Service Release 4.8.9 2011-02-18

  • Fixed: Bad log message in HTTP adapter in case of a HTTP 500 reply from the backend. The adapter logged a message containing the error reason "No HTTP response available", which was very misleading.

  • Improved: Support for Axsionics token (two new Struts mappings for two new Axsionics-specific model states, get.axsionics.number to display the new JSP AxsionicsEnterNumber.jsp (used to enter the serial number of the token), and get.axsionics.cred.challenge for displaying the new JSP AxsionicsChallengeResponse.jsp (for entering the response code). See "SLS Administration Guide", chapter "Axsionics", for details.

Secure Login Service Release 4.8.8 2011-02-10

  • Fixed: Bug in JSP tag inputField, which could lead to an exception, if the tag was used in a JSP while the SLS session had been invalidated already.

Secure Login Service Release 4.8.7 2011-02-04

  • Fixed: In the ELCARD "web.xml" template, the parameter "retry" of the ELCARD filter was set to false, but it should be set to true usually. The template has been changed accordingly.

  • Improvement: PasswordPolicy allows now the characters '[' and ']'.

  • Fixed: Bug in cookie header parsing, which could lead to a situation where the SLS would not recognize the "SlsInternalUserInfo"-cookie created by the SLS itself (which carries information about the authenticated user).

Secure Login Service Release 4.8.6 2011-01-27

  • New: Model property credentials allows to specific a list of credential types (per model) that must be presented and verified in order for the do.success state to complete successfully. This serves as an additional check, so that it's not just the back-end adapter who decides if all required credentials are available. See "SLS Administration Guide", chapter "Model" for details.

  • New: JEXL function function.getArraySize(), which allows to determine the number of entries in a given array.

  • New: JEXL function response.addHeader(), which allows to set a custom HTTP response header multiple times, with different values.

  • New: JEXL function function.isHspSessionStepUp(), which allows to check if the client currently requires to perform a step-up authentication, to reach a higher authentication level (from weak to strong).

  • New: JEXL function function.isHspSessionExpired(), which allows to check if the HSP session had expired (e.g. due to client inactivity).

  • Improved handling of first argument in JEXL function ldap.putLdapBackendSystem(), to avoid problems with several variations of alias prefixes. For example, providing ldap as the first argument now yields the same result as providing an empty string. Also, the documentation has been fixed accordingly.

  • Extended handling of HTTP OPTIONS method call. Until now, the SLS responded just with an allow header (which is correct in respect to the HTTP specification). But some WebDAV clients require to combine this response with the regular request processing, in order to trigger and perform GET-request-based authentication like NTLM. For this reason, the OPTIONS request now still sets the allow header, but otherwise is processed like a GET-request.

  • New: User filter mode property user.filter.blacklist can also be put into the sls-dynamic.properties file now. This allows to switch between whitelist- and blacklist-mode on the fly, without restarting the SLS.

  • Fixed: If a non-existent (not empty!) user filter file was configured in whitelisting mode, access for all users was blocked. Now, the whitelist will not really become active as long as the filter-file does not exist. Once it is created, all not-listed users will be blocked immediately. This allows to configure a non-existent file in whitelist mode first, allowing everyone access, and then blocking access in a case of emergency by simply creating an empty file.

    ## Secure Login Service Release 4.8.5 2011-01-05 ##

  • Updated and extended "SAML Service Provider" documentation chapter in "SLS Administration Guide".

  • Fixed: Added missing SAML SP jar-file "saml-sp-*.jar" to classpath of SLS web application again.

Secure Login Service Release 4.8.4

  • Fixed: Bug that prevented the SLS from starting up if a JEXL expression was used as the value for the DN of an LDAP tech user (caused by the migration of some JEXL functionality to a new USP commons code package).

  • Fixed: LDAP JEXL function putLdapBackendSystem() did not work anymore, and also required the given system to be in the list of configured systems anyway. The function now adds the given system as a new, additional one if it's not in the list of configured systems set. It also selects it to be used in the next operation of the given type (defined by the alias). See function documentation for details.

Secure Login Service Release 4.8.3

  • Improvement: check that the file list for the property user.filter.file is not empty. Throw an exception if it does.

  • Improvement: "SLS Administration Guide" User Filter chapter was revised and completed.

  • Improvement: the model and step information is now always shown when a model execution is canceled.

Secure Login Service Release 4.8.2

  • Fixed: Bug in "struts-config.xml", where the LDAP action had an adapter type none configured instead of ldap.

  • Challenge adapter of type smschallenge has been removed. Use the HTTP adapter to send the challenge to the SMS provider, and the basechallenge adapter to create the challenge and verify the response. See the corresponding chapter in the "SLS Administration Guide", "Challenge / Response" for details.

Secure Login Service Release 4.8.1

  • New: Configuration property challenge.lifespan allows to configure the validity period of the challenge (or rather response) generated by the internal base challenge adapter.

Secure Login Service Release 4.8.0

  • New: Trigger allow to perform certain JEXL functions triggered by the ID of the current user (based on a group of users defined in a file), combined with additional conditions that must be met. One use-case is to enable HSP trace-logging for certain users only. See "SLS Administration Guide", chapter "Triggers", for details.

  • New: JEXL function function.enableSesTraceLog() allows to switch on trace logging for the current session in the HSP.

  • Added chapter about "Concurrency Issues with Multiple Browser Tabs" in the "SLS Administration Guide", and how to address the problems surrounding them. The sample ntlm-adapter.properties and sls.properties configuration files have also been extended accordingly.

  • New: JEXL function session.getSessionAttributeValue(String,String,String) allows to retrieve the value field of a certain session attribute, if it exists (see JEXL Guide for details).

  • New: Trigger mechanism: dynamically triggered actions for a configured list of users. This allows to execute any arbitrary JEXL function in the model at any point, but only for a certain list of user IDs.

  • New: Added chapter "Triggers" to the SLS Administration Guide.

Secure Login Service Release 4.7.8

  • Fixed: The ordering of properties still had problems on certain platforms due to the way how Java's string comparison mechanism works. It was replaced by an independent sorting mechanism, so system locales should not have any influence anymore.

  • Fixed: In LDAP custom operation properties, JEXL expressions were resolved prematurely, resulting in invalid configuration settings at the time the LDAP operation was actually executed. JEXL expessions in such values are now resolved only once the operation is really performed.

Secure Login Service Release 4.7.7

  • Fixed: LDAP adapter custom error mapping did not work correctly for the password change functionality.

  • Fixed: LDAP adapter custom operation property groups with multiple operations (like a search-group with multiple searches over different DNs, using different filters etc.) were not always read in the correct order. The operations might have been executed in different order than they were numbered within the property group. Now the operations are executed in the order of their numbering.

Secure Login Service Release 4.7.6

  • Improved: Error Handling of Axsionics Adapter.

Secure Login Service Release 4.7.5

  • Fixed: LDAP Adapter custom actions did not work if no url was configured.

Secure Login Service Release 4.7.4

  • New: The property selfredirect.enable=true enables an automatic redirect to the SLS itself after every POST of form data. Background: If a user enters data into a HTML form and posts it, current browsers will cache the form data if the response to the request was a HTTP 200 - but not when it's a redirect (HTTP 302). In environments where computers are potentially shared by multiple users, one user could perform a complete login, and another malicious user could then later "replay" that login by pressing the "back" button of the browser in order to have it post the same form data again. The new property will let the SLS perform a 302 redirect to itself each time a POST request is processed. But because some existing clients (such as automated monitors) may have problems with that new behaviour, it's disabled by default).

  • New: A model can now have multiple URLs to be mapped to that model, like model.login.url.1=/auth, model.login.url.2=/certauth, model.login.url.3=/myauth etc.

  • New: Added configuration properties redirect.logout and forward.logout, which allow to configure a redirect or an internal forward to a certain location after a logout. See "SLS Administration Guide", chapter "Redirecting" for details.

  • New: Added model state get.useragent which displays the UserAgent.jsp file used by the browser blacklisting function. This allows to build a custom blacklisting mechanism or extend the existing one through a customized model and JEXL conditions.

  • Fixed incomplete validation of model configuration. Numbered nextState properties (like ...state.10.nextState.1=...) always require a JEXL condition, but the configuration validation did not check for that. Now the SLS will fail to start with an extensive error message in such cases. The model documentation in the "SLS Administration Guide" has also been adapted accordingly (added new chapter "Conditional Branching").

  • Changed Spnego adapter config files from Krb5-realm.conf to krb5.conf, and from Krb5-princ.conf to spnegoLogin.conf, to be in line with what they are called in general.

  • New: Introduced a generic "Challenge-/Response" adapter, which can create random numbers or strings that can then be sent to the user by means of other adapters, JEXL functions etc. The adapter is then also used to verify the response code.

  • Improved "Administration Guide": Added chapter about "Challenge / Response" procedures, and how to set up challenge-/response authentication with SMS, using the HTTP adapter.

  • Improved "Administration Guide": Added JSP file mapping information to all JSP model state documentations, added model state get.useragent, extended documentation about nextState and failedState properties in models.

  • Improved JEXL Guide by adding "Since: SLS ..." tag, which documents for each JEXL function the SLS release version which introduced that function. Also, some functions now have code examples added.

  • The title pages of the "JEXL Guide", "Taglib Guide" and "Log Messages" documents now contain the SLS release version and date.

  • New: JEXL Functions response.propagateBasicAuthHeaderToApp(String, String) and response.propagateBasicAuthHeaderToApp(String, String, String) allow to propagate a custom Basic-Authentication header to the target application server through a single JEXL action in a model.

  • New: JEXL Functions session.getUserInfoValue(String) and session.setUserInfoValue(String, String) to set and get values from the User-Info Cookie.

Secure Login Service Release 4.7.3

  • Fixed: LDAP Adapter failover support for custom operations did not perform a fallback to the global default LDAP url (ldap.url) anymore if no URL was defined for a custom action at all.

  • New: JEXL function function.clearAllAdapterAttributes(String) allows to clear out all attributes of a certain adapter type (such as ldap or radius) in the current login session.

  • New: JEXL function session.processNextGETasPOST() allows to implement custom login or challenge / response processes that use multiple GET requests instead of POST requests.

  • Improved documentation of "regex" mode setup for Tomcat Authenticator and J2EE Filter in "SLS Administration Guide", chapter "SSO Integration".

Secure Login Service Release 4.7.2

  • New: RADIUS adapter now also supports simple round-robin failover between several RADIUS servers. To use this functionality, the configuration property holding the RADIUS server hostname can now hold a comma-separated list of host names. All other values (such as ports or shared secret) must be the same for all RADIUS servers as of now. This may change in a future release.

  • New: RADIUS adapter now also supports user ID mapping through the do.mapping model state, if configured. In that case, the resulting JEXL variable special.mapped.id will contain the value of the RADIUS response attribute used as a user ID value.

  • Fixed: RADIUS adapter now supports simple challenge-/response authentication as defined in http://www.ietf.org/rfc/rfc2865.txt. The login model has been changed accordingly. Re-sending of the RADIUS State attribute is handled by the adapter automatically. There is also a new JEXL variable available, radius.response.type, which contains the numeric value of the RADIUS response code, allowing for custom response handling through actions in the login model etc. See Administration Guide for details.

  • Changed: JEXL variables for RADIUS response attributes are now created with the name attribute.radius.type<no/> (for backwards compatibility reasons, they are also still created with the old name attribute.radius.<no/>). The reason for changing the name is that JEXL treats variables with a name that ends with a dot followed by a number as array indexes (meaning myvar.3 is equals to myvar[3]). This leads to many problems when dealing with RADIUS response attributes in JEXL scripts, or requires the use of variable handling functions. With the new name pattern, this problem has been eradicated.

  • Fixed: LDAP adapter now supports failover also for so-called custom LDAP actions (performed during the do.ldap model state). So in other words, everywhere where LDAP urls can be defined, it is possible to define a comma-separated list of URLs in order to get simple round-robin failover between those LDAP servers.

Secure Login Service Release 4.7.1

  • New: Extended functionality for the SOAP frontend. It is now possible to define a status message and / or a list of optional attributes (key-/value-pairs), using JEXL expression, to return additional information to the SOAP client.

  • New: Documented SLS response headers "SLSStatus", "SLSError" and "AccessArea" in the "SLS Administration Guide" (new chapter "SLS Core" / "Headers").

  • Fixed: Bug in handling of "tech" user principals in LDAP adapter, which could lead to connections made with invalid credentials, or failing due to missing credentials under certain circumstances.

  • New: Added JEXL functions function.sha256() and function.sha512() to create a hash using SHA-256 or SHA-512.

Secure Login Service Release 4.7.0

  • New: SOAP Frontend allows programmatic clients to perform authentication over the SLS, using a SOAP interface. See "SLS Administration Guide", "Frontend" / "SOAP Frontend" for details. The interface is still very basic right now and will be extended in future releases to support more complex login models.

  • Experimental: New PERL-based "validator" command line tool allows to validate an SLS installation (Tomcat instance) in order to detect / avoid certain potential problems, such as jar file version conflicts, invalid permissions etc. Once the tool is finalized, it will be documented in the "SLS Administration Guide". The tool can be found in the SLS web application in the tools folder. See readme.txt for usage details.

  • Improved: Logging of failover events. Older SLS versions only logged the message FAILOVER_PERFORMED, when the failover procedure was done. This lead to the confusing fact, that without any logged reason there could occur FAILOVER_PERFORMING events. Now, there is an additional log message FAILOVER_PERFORM when the failover procedure is started.

  • Changed: Added prefix "usp-" to the Jar file names of the J2EE filter and the Tomcat Authenticator, in order to prevent potential naming clashes with other 3rd party libraries. The same naming prefixes will be used for all other future SSO modules and libraries.

  • Changed: JEXL functions function.setVariable() and function.getVariable() can now be used on all types of variables (parameter and return type Object), not only Strings. Which can be useful to combine these methods with array handling functions.

  • Fixed: Multi-Value attribute handling always dropped the first attribute. All attributes are now being used. Also fixed incorrect logging.

  • New: JEXL function function.contains(Object, Value) checks if the object contains the value. function.contains can deal with arrays and simple objects.

  • Changed: Added explanations about parameter types in jexl-guide.pdf. A few minor formatting issues in this document were also fixed.

  • Changed: The model state show.jsp was previously only available with the sls-core-*-tests.jar in the classpath (the library which also contains mock-up implementations of back-ends). The reason was that originally this action was meant to be used for JSP development purposes. But as it has become quite useful for more flexible model setups, it has been moved to the regular main jar library.

  • Removed: Obsolete configuration property prefix character.illegal. was removed, because this whole "illegal character" check mechanism has become obsolete by the introduction of the "parameter checker" some time ago. The hard-coded internal checks for 'evil' characters such as < and /> have been removed as well. In order to prevent the use of such characters, the parameter checker must now be configured accordingly, or the HSP / SRM.

Secure Login Service Release 4.6.2

  • New: Added command line utility usp-ses-ticket-tool-1.0.0.jar which allows to create keys and / or key index files that can be used to create or verify SES tickets.

  • Changed: The model state show.jsp now not only processes the request parameter jsp, but also the state property (or parameter jsp). So it is possible now to display any JSP within a model using the show.jsp state. See "SLS Administration Guide", chapter "Model", for details.

  • Fixed: Eliminated unnecessary WARN log messages of new JEXL 2 provider.

Secure Login Service Release 4.6.1

  • Fixed: Broken formatting of JEXL Guide documentation.

  • Changes in Parameter Checker:

    • The attribute .uri is now optional. New parameter-checkers without uri are ALWAYS executed, for each request, for GET and POST requests. They are executed before a credential can be created. In contrary to the above, parameter-checkers with an uri are only for POST requests, and they are executed after the credential creation.

    • There is a new attribute .neverlog=true|false which will create a password filter at the moment the checker is executed. So the filter can for example be activated for misspelled passwords.

Secure Login Service Release 4.6.0

  • Changed: The jar file for the Tomcat Authenticator, tomcat-authenticator-*.jar, includes the JAAS and SES ticket API classes as well, in order to simplify deployment a little. As a result, the files ses-ticket*.jar and jaas-*.jar are not necessary anymore.

  • Changed: The jar file for the J2EE servlet filter, j2ee-filter-*.jar, includes the SES ticket API classes as well, in order to simplify deployment a little. As a result, the file ses-ticket*.jar is not necessary anymore.

  • Fixed: Tomcat Authenticator behaviour in case of missing authentication information, if requireValidUser is set to false corrected; HttpServletRequest.getRemoteUser() now also returns unknown instead of null.

  • New: J2EE Servlet Filter and Tomcat Authenticator config settings (denyResponseCode and denyReponseMessage) for defining the HTTP response code and message in case of an "access denied" situation. Furthermore, the default HTTP response code for this has been changed to 401 (from formerly 403), as this is more appropriate for access being denied due to lack of authentication.

  • New: The attribute <<additional/>/> is available for all custom sls-tags that render a HTML tag. With this tag any attribute can be added to the rendered tag.

  • Improved "SLS Administration Guide", with additional use case examples (like combining weak and strong authentication, determining authentication or authorization state etc.) and detailed documentation on how to create specific custom SES session attributes.

  • New: JEXL functions session.hasSessionAttribute() and session.getSessionAttributes() allow to access SES session attributes. For details, see new "SLS Administration Guide" chapter about SES session attributes.

  • New: The JEXL scripting engine has been upgraded from 1.1 to 2.0, due to some internal improvements and optimizations. It provides better error messages, but there can be some changes in behaviour compared to JEXL 1.x in a few circumstances. It is also possible to make JEXL 2 behave more or less strict, having it throw exceptions if a null object reference is used, instead of just not processing an expression silently (like JEXL 1). In case of severe compatibility issues, JEXL 1 can be activated through a configuration property. See "SLS Administrators Guide" for details.

  • New: JEXL credential provider allows to create / update credentials based on JEXL expression, independently of the current model. See "SLS Administration Guide", chapter "Credential Providers" for details.

  • New: JEXL function function.getTemplateContent() allows to process a local template text file (preconfigured using the new configuration properties with prefix template.file.) and use the contents of the file in any subsequent JEXL operation, response header, ticket etc. This function also works recursively (a template contain this function call to embed another template inside it and so on). See "JEXL Expressions" chapter of "SLS Administration Guide" for details.

  • New: JEXL function function.hasNonEmptyVariable(String) allows to check if a variable exist, and that it also contains an actual value other than an empty string or null.

  • New: Log4j appender which uses local Unix / Linux "logger" binary to support local syslog instead of network syslog host. See sample log4j configuration for details.

  • New: Log4j appender which allows to pipe log output into any local executable binary. See sample log4j configuration for details.

  • Changed: "Multimandator" --> "Multitenancy": Now, we do use the more common word "tenant" instead of "mandator". All configuration properties are also renamed, but the old property names are still supported.

  • New: Custom SLS Log4j variable %X{state} allows to log the current model state in every log message.

  • New: Custom SLS Log4j variable %X{tenant} allows to log the current tenant value in every log message.

Secure Login Service Release 4.5.5

  • Fixed: Username and password credentials with special characters sometimes caused problems when they were used with AAI in the SES reverse proxy. An enhancement of the internal protocol between SLS and SES now uses URL-encoding for such string values. Note: This new functionality must be enabled with the new config property session-attribute.encodings=true in order to remain backward compatible with old SES proxy versions.

  • New: JEXL function response.setSesSessionAttribute(String, String, String, String, String) allows to create arbitrary SES session attributes and setting their encoding type.

  • Changed: Tomcat Authenticator configuration properties authentication.signkeyfile and keyindex were deprecated and replaced with the new property authentication.keyindex (the old two were redundant and, in one case, misnamed).

  • New: J2EE filter now provides the same functionality as the Tomcat Authenticator, namely using a "REGEX" authentication mode where a freely configurable header can be used, consisting of key-/value pairs and optionally a signature and a timestamp.

  • New: ISAPI filter DLL adds support for SES ticket based SSO with ASP (Active Server Pages) applications running on IIS (Microsoft Internet Information Server).

  • Changed: Improved documentation of J2EE filter, ISAPI filter and Tomcat Authenticator in the "SLS Administration Guide", chapter "SSO Integration".

  • Changed: J2EE filter now uses "Jakarta Commons Logging" instead of Log4j, which allows to use the logging framework of choice.

  • New: JEXL function response.createCookie(String name, String value, String path, String domain, int maxAge, int version). In addition to the older createCookie() method the cookie version 0 or 1 can be defined.

  • New: JEXL function session.getMandatorSpecific() enables multi-mandator support for dedicated SLS features.

  • New: "Browser-Blacklist" can contain mandator specific entries.

  • New: "Parameter-Checker" can contain mandator specific entries.

Secure Login Service Release 4.5.4

  • New: JEXL function function.getAdapterType(String) which allows to determine the type of the adapter ("ldap", "radius"...) used for a certain kind of operation ("authentication", "mapping").

  • New: JEXL function function.timestamp() for creating a timestamp.

  • New: JEXL function function.addTimestamp(String) for creating a timestamp and adding it to an existing data string.

  • New: JEXL function function.addSigAndTime(String) for creating a timestamp and signature for a given data string and adding both to that data string.

  • New: JEXL function function.sign(String) for creating a signature for a given data string.

  • New: JEXL function session.getMandator() returns the currently active mandator, if multi-mandator support has been enabled.

  • New: Support for multiple files for filtering users (whitelisting or blacklisting of users by login IDs), and for using a dynamic file (updated on every request).

  • Change: Improved Tomcat Authenticator with timestamp check to prevent replay attacks and usage of appropriate HTTP return codes.

  • New: Experimental support for RSA 7 servers with a new SecurID adapter.

  • Fixed: Eliminated confusing "adapter has no type" error log message in some cases of invalid adapter configuration.

Secure Login Service Release 4.5.3

  • New: Support for integration with ELCARD matrix card authentication service (see SLS Administration Guide, chapter 36 "ELCARD" for details).

  • New: Support for BID-check (browser ID) functionality has been included. If the new configuration property bid.check.enable is set to true, a new JSP tag head renders some CSS and JavaScript statements in the page HEAD section required for the BID check. Corresponding to that, the mandatoryFooter JSP tag renders the additional JavaScript code required at the bottom of the HTML page (must be after the form).

  • LDAP error code mapping has been extended in that it is now also used for AuthenticationException and CommunicationException types, not only generic NamingException. The reason is that some LDAP directory server return special state information in generic NamingExceptions, other in more specific AuthenticationExceptions.

  • LDAP error cause logging has been improved by always including the last used bind principal and the causing exception name and message.

Secure Login Service Release 4.5.2

  • Change: The File-Adapter now allows to configure the location of the XML file user-config.xml both as an absolute or relative path. See SLS Administration Guide, paragraph 30.3.1 for details.

Secure Login Service Release 4.5.1

  • Change: The various back-end adapter Administration Guides and the SAML documentations have been merged with the SLS Administration Guide.

Secure Login Service Release 4.5.0

  • New: DEBUG and TRACE logging can be enabled for single sessions, either interactively through the "Info Portal", or based on user login IDs, set in lists through configuration properties in the sls-dynamic.properties file (which is processed for every request). See SLS Administration Guide, chapter 7.4, for details.

  • Change: The "Info Portal" GUI frontend, which allows to determine the status of the SLS, login sessions, configuration settings and more, now only uses Basic Auth through the local user-config.xml file for its own access control. Also, the "Info Portal" now allows to activate DEBUG or TRACE log for single sessions and even downloading the log records from the sls.log file. See SLS Administration Guide, chapter 24.4, for details.

  • Change: The RSA SecurID adapter now allows to configure the path of the generated rsa_api.properties configuration file, instead of insisting on the SLS webapp WEB-INF directory. See RSA SecurID Administration Guide, chapter 3, property securid.rsa.api.file.dir, for details.

Secure Login Service Release 4.4.0

  • New: The Tomcat authenticator and the JAAS module (in tools/appserver/) do not use log4j directly anymore. These modules now use only references to the Apache commons logging framework.

  • New: JEXL function failWithCustomError allows to create an authentication error from within the model, which will result in a custom error message being displayed to the user. So while the internal SLS error ID is always the same, this function allows to directly provide the key of the end-user message in the SLS message resource file(s), instead of using the usual error mapping mechanism.

  • New: Model state names can now optionally have a suffix like -xyz. This allows to distinguish multiple states in a model which have the same name (such as do.generic) and reference them still by a name instead of the number. This eliminates the need to re-number references in conditional branches if new states get inserted, or states are deleted.

  • New: Basic Auth can be enabled only for certain User-Agent header value types, using regular expressions defined in configuration properties with the new prefix basic.auth.match.. If such regular expressions are defined, the User-Agent header value of an incoming request will be checked, and if it matches any one of them, Basic Authentication will be used instead of a JSP form (see chapter "16.3 User-Agent Header Matching" of the "Administration Guide").

Secure Login Service Release 4.3.11

  • Fix: If a numbered "failedState" (like "..failedState.1") also had a condition, a configuration error occurred. This has been fixed, and the error log messages have been improved.

  • Fix: In the LDAP adapter, if custom actions with custom URLs were defined, the back-end monitoring mechanism always used the "default" principal for monitoring those back-ends. Now, if specific custom principals are defined for such actions, those principals are also used for monitoring the corresponding LDAP back-end system.

  • Fix: JEXL documentation did not show array parameters as arrays, e.g. mergeArrays(Object[] arrayOne, Object[] arrayTwo) was instead shown as mergeArrays(Object arrayOne, Object arrayTwo).

Secure Login Service Release 4.3.10

  • Bugfix: Base64-values in parameters for redirect URL sometimes weren't URL-encoded at all. This has now been fixed to make sure a redirect location URL with a base64-value in a URI parameter will always have that value properly URL-encoded.

  • Bugfix: the JEXLfunction clearAuthorizations() was not working properly.

  • New: JEXL functions function.dataProtectorEncrypt and function.dataProtectorDecrypt allow to use the DataProtector facility to encrypt or decrypt custom values (for example in a header that would be propagated to an application).

  • New: JEXL function function.addToArray allows to add a single object to an existing array.

  • Changed: The JEXL array handling functions function.mergeArrays, function.sortArray and function.arrayContains use java.lang.Object for their input parameters and return values, instead of strings. This allows to use those utility methods also in conjunction with other functions which create any kind of arrays, not just strings.

  • Fixed erroneous double-URL-encoding or parameters in the RequestedPage URL. Now the SLS URL-decodes each parameter value once and then re-encodes it again if necessary.

Secure Login Service Release 4.3.9

  • New: "if"-attribute for models allows to trigger a model through a matching JEXL condition, instead of a URI path or SES session credential state.

  • New: The old behaviour - when an already known req-parameter is sent again to the sls - was to log a warning and forward to jsp.usererror. This old behaviour does not seem to be very user friendly, since a user could just reload the page and get an error. The new default is: The sls just ignores the duplicated req-parameter. If for some reason the old behaviour is required, it can be enabled by setting legacy.reqparam.reusing.ignore=false.

  • New: Configuration property names (keys) are no longer case-sensitive! This means that, for example, the property debug.info in the sls.property file can also be named Debug.Info or DEBUG.INFO, every name will work. This helps avoid time-consuming searches for strange problems caused by minimal typos or copy-paste errors. Note: The property values remain case-sensitive.

  • New: Some states in a model can now be configured dynamically through new properties named model.<modelname/>.state.<no/>.param.<paramname/>=value. This new mechanism is more flexible than the previously used .property in that it allows to use multiple named parameters per action.

  • New attribute stateNumber in JSP tag ifModelTag. Allows to specify the expected state by the precise number instead of the potentially unspecific state name.

  • New: JEXL function function.createEncryptedTicket(), which allows to create an SES ticket which is completely encrypted itself (ant not just signed, with optional payload encryption).

  • New: JEXL function function.getCookieValue() for retrieving the value of a cookie (if it exists).

Secure Login Service Release 4.3.8

  • New jexl functions session.clearAuthorizations() for removing all authorizations of usage type ac-app-az

  • New jexl function session.removeAuthorization(authorizationId) for removing one authorization of usage type ac-app-az.

  • Fixed: Using a JEXL Expression like failWithAuthenticationException could trigger that exception at startup in rare circumstances.

  • Deprecation: Configuration.getProperty() is deprecated. Use getMandatoryProperty instead.

Secure Login Service Release 4.3.7

New: New Error Message if Connection to the Ldap Backend fails.

Message.ERR_UNKNOWN_HOST

Fixed: Invalid initialization of adapters that are in the

classpath, but did not have any valid configuration (and were
really not used by the SLS instance).

Fixed: Problem of incorrect logout signalizing to SES:

The `AccessArea` header can be set to `Invalidate`
or `Invalidate_All` independent of the `SlsStatus`.

Secure Login Service Release 4.3.6

  • New: The Controller invalidates the SlsSession if a SlsException signals a general problem. In this case the SLS displays a HTTP 500 error. The old behaviour (not invalidating the SlsSession) can be forced by enabling the new configuration property legacy.500error.noreset=true.

Secure Login Service Release 4.3.5

  • Alpha: Added new JEXL Function to override session-sticky LDAP backend system.

Secure Login Service Release 4.3.4

  • New: If a request contains more than one Cookie headers we do read all of them. Before this version we considered only one of the header lines, and ignored other lines which also start with Cookie.

  • New: If a request contains more than one cookie with the same name (case sensitive) a warning is logged.

  • Fixed: ChangePasswordAction can handle a not-existing old password. (If the adapter supports this feature, i.e. SecurIdAdapter.)

  • New: Config property for SecurIdAdapter to disable automatic concatenation of the password to the secret. <<rsaadapter.pwdcred.autoconcat.disable=true/>/>

Secure Login Service Release 4.3.3

  • New: small change to the generic soap adapter to allow non-generic adapters to work not only as authentication but also as any kind of adapter.

  • Fixed: Invalid initialization of adapters that are in the classpath, but did not have any valid configuration (and were really not used by the SLS instance).

  • Fixed: Broken monitoring of back-end connectivity (only for status indication in log; did not impact the failover mechanism).

Secure Login Service Release 4.3.2

  • New: Added password change functionality in LDAP adapter.

  • Fixed: Proper back-end system unavailable error message for the RADIUS adapter when the connection to the RADIUS server timed out.

Secure Login Service Release 4.3.1

  • New: Config property 'req.wrapped.marker=xyz' that overwrites the default marker for a req-parameter that is wrapped into a requested page value. Detailed Explanation (Fixing bug #3794): The requested page can contain a wrapped req parameter. This wrapped parameter is marked inside the requested page by the pattern <marker/>=<req-param/>. The SLS just parses the requested page for the marker, and if found, the requested page is cut at this place. The default marker is defined by IReqParamConstants.REQ_PARAM. This leads to "req" as default marker. If problems occur because in an environment "req" is a common substring of the RequestedPage, this property can be set to define a custom marker.

Secure Login Service Release 4.3.0

  • New: The Parameter Checker can now expect a match to a java regex as a requirement for a parameter. The new suffix for the parameter checker property is: .fullregex=

  • New: Dynamic config properties in sls-dynamic.properties

  • New: Configurable load information header.

  • New: Dynamic config property "load.header.overwrite"

  • New: Dependencies (jars) for sls-core are updated.

  • New: Regular expressions for valid requested pages can be configured: requested.page.whitelist and requested.page.blacklist Invalid requested pages are just ignored.

  • Fixed: Password filter (for never logging passwords) is saved in SlsSession now, but only in Storage before.

  • Fixed: Reuse of encrypted req-parameter (potential reply attack) leads to UserError.jsp. (Before it was HTTP 500 and SystemError.jsp)

  • Fixed: The tag sls:staticResourceTag includes the closing bracket "/>".

Secure Login Service Release 4.2.1

  • New: LDAP adapter allows to perform anonymous binds by setting the name of a principal to anonymous.

  • New: dynamic properties: for this sort of properties it is not needed to restart the application server in order to new load them. New functions Configuration.getDynamicProperty(...).

Secure Login Service Release 4.2.0

  • New: Custom SLS Log4j DailyRollingFileAppender, which combines the abilities of the standard Log4j appenders RollingFileAppender and DailyRollingFileAppender. It allows to define a maximum file size and number of rotated files to keep per day, but it also allows to specify the maximum number of days for which to keep rotated files. Therefore it basically eliminates the need for any kind of external file rotation or clean-up tool.

  • New: JEXL functions function.getSlsErrorId() returns the SLS message ID of the last error (if there was one in the current request) while function.getSlsErrorMessage() returns the message text. This allows to implement conditional branching to different failedStates in the login model based on the error message ID or text.

  • Massively revamped DEBUG and TRACE logging. While DEBUG logging has been reduced by a large margin, most information useful only to USP developers has been changed to TRACE log level. This means that DEBUG logging now provides a lot more useful information to the SLS administrator trying to figure out the reason for a problem himself by activated DEBUG log level.

  • Fixed: Broken automatic decryption of configuration properties that are encrypted with the DataProtector tool. Only properties in the sls.properties file were still decrypted, all others not at all. This has been fixed, so all adapter configurations etc. are now being processed correctly.

Secure Login Service Release 4.1.29

  • New: Custom SLS Log4j Syslog appender which allows to specify the "TAG" (aka Identity) value and prevents exception stack traces from being written to syslog.

  • New: Custom SLS DailyRollingFileAppender which also allows to specify a maximum file size and number of rotated files to keep within one day (basically a mixture of the Log4j RollingFileAppender and the DailyRollingFileAppender functionality).

  • New: "Operations Guide" with instructions for monitoring, debugging and maintaining SLS instances replaces the previously included "Monitoring Guide".

  • New: Sending of RequestedPage to client (in form of a hidden post parameter added to sls:FormTag can be disabled by a config property. The requested page is new encrypted in the parameter (in older versions it was plaintext). If debug.info is set to true, the parameter is also added to the page as an unencrypted comment.

  • New: JEXL function session.setAccessAreaLevel() for adjusting the SES access area level dynamically from within the login model.

  • New: JEXL functions for date formatting and parsing (formatDate(), formatCurrentDate(), parseDate() - see jexl-guide.pdf for details).

Secure Login Service Release 4.1.28

  • New: New session variable challenge for allowing the definition of the HTTP request body direct in the config file of the http-adapter.

  • New: JEXL-function for writing a custom log record to the audit log file: function.loadAudit().

  • New: JEXL-function for triggering an authentication failure: function.failWithAuthenticationError().

  • New: JEXL-functions for removing session credentials: session.clearCredentials() which removes all currently available credentials, and session.removeCred() for removing one credential of a certain semantic type.

  • Improved trace-logging and reduced debug logging

Secure Login Service Release 4.1.27

  • Fixed: Bug in URL encoding of parameters in redirection URL (parameters without a value were swallowed or concatenated with other parameters).

Secure Login Service Release 4.1.26

  • Base for CS-SLS-4.3.0

  • Fixed: Failover (and Loadbalancing) strictly use Round-Robin when all backends are unavailable.

Secure Login Service Release 4.1.25

  • Changed: For the last release (4.1.24) a fix was planned 'avoiding multiple cookies'. It was not implemented. Now a WARN log is written, when a cookie is added more than once to the request. (Tomcat's servlet-api will generated multiple Set-Cookie headers with the same cookie name.)

  • New: Optional persistent SLS client cookie which allows to improve handling of concurrent login requests caused by multiple tabs in a browser window, especially with automatic login procedures, such as NTLM or Kerberos.

Secure Login Service Release 4.1.24

  • Fixed: Broken JEXL-function response.setCookie() which didn't really create a SET-COOKIE-header.

  • New: Configuration properties ses.ticketapi.keyId and ses.ticketapi.keyIndexFile for the definition of a keyfile and a key inside it for the SES ticket API which may be used for various encryption / decryption signing / verification purposes.

  • New: Extension of SES Tomcat Authenticator. Verify signature from header.

  • Fixed: Delete UserInfo cookie when performing a logout by setting hspAccessArea=invalidate. This prevent recreation of old values from UserInfo cookie in new SlsSession.

  • New: It's now possible to set max-age instead of expires in a configured cookie. Just use cookie.<NAME/>.version=1.

  • Fixed: StringIndexOutOfBoundsException in new stdout/stderr to Log4j redirection facility. Also added new logging of internal information in case of an error, and automatic disabling of the facility.

Secure Login Service Release 4.1.23

  • New: Added JEXL functions to find out the current session locale / language codes.

  • Improved handling of concurrent form-based authentication requests from multiple browser tabs, in order to make sure that each tab still is redirected to its actual requested URL.

  • Improved handling of concurrent NTLM authentication requests in multiple browser tabs, in order to avoid popup-authentication dialog boxes.

  • Fixed: Issue with decryption of "SLSuserId"-cookie in existing SES session after restart of the SLS.

  • Change: Configuration property already.loggedin.active has been deprecated and replaced with the new property already.loggedin.page.

  • New: Configuration property already.loggedin.redirect allows to redirect clients that send requests to the SLS while already having an authenticated SES session back to their requested page URL. Otherwise, they are being presented with the login page or a "you are already logged in" page, depending on the configuration.

  • New: standard out and standard error are now redirected to the Log4J facility with the named category "stdout", shortly after the start of the SLS web application. This prevents the non-rotatable catalina.out from growing endlessly over time. Note that Tomcat may still generate output in catalina.out depending on the configuration of its' own internal logging.

Secure Login Service Release 4.1.22

  • New: Extension of SES Tomcat Authenticator. Extract user credentials from header using a regular expression.

Secure Login Service Release 4.1.21

  • Fixed: Bug in internal safety cross-check, concerning setting of the AccessArea header and SES session attribute headers.

  • Improved formatting of JEXL Guide PDF file.

Secure Login Service Release 4.1.20

  • New: Specific model can be triggered based on a missing authorization signaled by the HSP (see the Administrators Guide, Chapter "2 Usage Scenarios" for details).

  • New: 3 new JEXL functions for handling missing authorizations can be used for custom branching, performing custom actions or display corresponding messages in a page.

Secure Login Service Release 4.1.19

  • New: Counter objects for JEXL expression allow to implement simple counter logic in the model (see the Administrators Guide, Chapter "21 JEXL Expressions" for details).

  • Fixed: Potential NullPointerExceptions in message logging code in case that a message key for a mapped error does not exist.

Secure Login Service Release 4.1.18

  • Fixed: Problem in j2ee-filter; even if it was configured that the user is not required (requireValidUser=false) the missing header lead to an Exception in the filter.

  • Fixed: Bug in back-end monitoring functionality, which caused problems if internal configuration properties existed for adapters that did not have any actual configuration.

Secure Login Service Release 4.1.17

  • Fixed: Renamed XML attribute nummeric to numeric in password policy file; nummeric is now deprecated.

  • New: Password policy allows now for only a subset of defined rules to be met by password in order for the check to succeed. Also, some numeric values have been replaced by strings (see Admin Guide for details).

Secure Login Service Release 4.1.16

  • Fixed: Bug in Adapter factory which caused startup-errors if an internal properties file existed for an adapter without an existing configuration file.

Secure Login Service Release 4.1.15

  • Fixed: In 4.1.14 the IfHasGlobalErrorTagHandler used Java 6 API functions in some circumstances. Now it works again with Java 5.

  • Fixed: Since 4.1.11 there was a Java-Script error in submitForm() for link-buttons generated by the ButtonTagHandler.

  • New: Password policy allows to use a freely configurable regular expression with the new XML tag regularExpression now.

  • Fixed: Password policy used the maxLength value also as the length for a generated random password, which is not always appropriate. A new config setting generatedLength has been added to optionally define the length of a generated password.

  • Key for error-mapping do.not.display does now also affect the <sls:ifHasGlobalError/> tag.

Secure Login Service Release 4.1.14

  • Tag Library Extensions, for details see tld:

    • <sls:button/> tag has new buttonType="input attribute.

    • <sls:button/> tag has new value=<String/> attribute.

    • <sls:ifHasGlobalError/> has new attribute: invert=true|false

    • <sls:ifHasGlobalError/> has new attribute:skipIfEmpty=true|false`

  • New configuration property javascript.minimal=true|false

  • New key for error-mapping: Mapping an error to do.not.display will lead to not display the message.

Secure Login Service Release 4.1.13

  • Fixed: SecurID adapter set JEXL variable rsa.auth.status with wrong value in certain cases.

Secure Login Service Release 4.1.12

  • Fixed: Change password action did not check if the new password is the same as the old one (which is never allowed).

  • Changed: BaseTagHandler produced to much DEBUG log. Now tracing is logged only in level TRACE.

  • New: Added a log entry (level INFO) when a backend system's skip counter is back to 0.

Secure Login Service Release 4.1.11

  • Fixed: Custom LDAP lookup operations did not create JEXL variables for attributes of found LDAP object.

  • Fixed: from sender mail address could not be configured for mail with generated password sent by "forgotten password" process.

  • Added: mail receiver address for mail with generated password can now be overridden through a configuration property (instead of being provided by the adapter).

  • Fixed: Random passwords generated in the "forgotten password" process will not contain ambiguous characters, such as "0", "O", "1", "I".

Secure Login Service Release 4.1.10

  • Fixed: UspSmsRandomChallengeAdapter did not verify credential CHALLENGE.

  • Fixed: Jexl function.regex(regex, input) can now evaluate to an empty String without exception.

  • Changed: The parameters in Jexl function.regex(regex, input) are not any more switched when it evaluates to "".

Secure Login Service Release 4.1.9

  • Fixed: Bug in RSA SecurID Adapter (handling of "next tokencode")

Secure Login Service Release 4.1.8

  • New: Jaas Login-Module and Tomcat specific SES-Ticket-Authenticator. This allows an application to get informations about a user from Ses-Ticket.

  • New: The file password-policy.xml can be removed. If the file is absent a 'void' policy becomes active. This void policy does not demand any requirements about the password.

Secure Login Service Release 4.1.7

  • Fixed: Correct handling of selected token in UserInfo cookie.

  • New: Generic LDAP actions added for model. This allows to perform various custom LDAP operations at any time in the login model, including updates or removals of attributes, searches with filters etc.

  • Improved LDAP adapter admin guide and sample configuration.

  • New: LDAP Error Mapping

Secure Login Service Release 4.1.6

  • Added: Do not any more allow duplicated configuration properties. The SLS will not start, if the same configuration property is defined twice. An Error message will be logged.

  • Fixed: Problem with duplicated SLSuserId Cookie.

  • Added: Log (to audit-log) the initial reason of a failed login in "Fake"-Mode.

Secure Login Service Release 4.1.5

  • Fixed: Filter for "evil" characters in JEXL variables accidentally also filtered blank (space) characters.

  • Fixed: User filter handling was broken due to bug in initialization procedure.

  • Fixed: Path for file which holds persistent statistics data was not configurable due to bug in handling of name of the configuration property.

Secure Login Service Release 4.1.4

  • Added: Documentation in "Admin Guide" for SLS session handling, JEXL special variables and timestamp settings

  • Fixed: Made session clean-up interval configurable with config property session.cleanup.period

  • Fixed: User filter thread is now always running, even if the specified filter file does not exist. In that case, filtering is basically inactive, and all users are granted access.

  • Added JEXL function for dynamically setting "AccessArea" level from within login model (instead of pre-configured global value).

Secure Login Service Release 4.1.3

  • New: Extended the LDAP adapter and added the new, generic do.ldap model state, for allowing dynamic LDAP operations during any point of the model.

  • New: JEXL-variable "attribute.ldap.sls.user.dn" contains the DN of the user object found in the last LDAP lookup.

Secure Login Service Release 4.1.2

  • Fixed: ButtonTag did not work when function="cancel".

  • Fixed: MetaRefreshTag did not load RequestedPage.

Secure Login Service Release 4.1.1

  • New: Generic Loadbalancing Function for supported adapters.

  • New: Generic Failover Function for supported adapters.

  • New: Taglib extension, InputFieldTag can handle maxLength attribute.

Secure Login Service Release 4.0.18

  • New: Various JEXL functions for accessing and checking adapter attributes, and for HTML en- and decoding.

  • New: JEXL variable "current.mandator" for accessing the current mandator alias.

  • New: Automatic compression for very large cookies.

  • New: Warn log message if cookies are created that exceed the size of 4 kb.

  • New: Basic support for HSP load information HTTP response header based on number of SLS sessions.

  • Various minor fixes and improvements.

  • Fixed setting of SES session attributes without an appropriate AccessArea.

Secure Login Service Release 4.0.17

  • Various minor fixes and improvements

  • Improved performance log for more accurate measurement of SLS-internal processing and back-end callouts.

  • Overall performance improvements

  • New: Preferences-cookie which allows to define parameters sent from the browser to be stored as user preferences.

Secure Login Service Release 4.0.16

  • Various minor fixes and improvements

  • New: Extensible abstraction of authentication tokens and token selection during login process.

  • Extended "userInfo"-cookie to serve as a generic storage for keeping user information during the lifetime of the HSP session.

  • Added various new JEXL functions

Secure Login Service Release 4.0.15

  • New: SLS-Taglib --/> JSPs without Java Code.

  • New: Multi-Mandator-Feature

  • New: State dependent error messages.

  • New: Cookie domain not mandatory anymore.

  • New: Name of language cookie is configurable.

  • New: View all JSP in the /showjsp model.

Secure Login Service Release 4.0.14

  • No new features in this release.

Secure Login Service Release 4.0.13

  • New: Support for branching in a login flow, based on conditions (defined with logical JEXL expressions).

  • New: Support for implementing custom JEXL expressions to add custom functionality to the login process (see Administration Guide for details).

  • New: Support for transaction verification has been incorporated into the SLS core framework.

  • New: Support for fake logins (a failed step in a multi-step login will not show a proper error message but let the user continue, in order to prevent certain types of guessing / brute force attacks).

Secure Login Service Release 4.0.12

  • New: a fully-featured file adapter which uses a local XML file to authenticate users.

  • New: the SPNEGO adapter which supports Kerberos-based authentication with Windows AD servers.

  • Added support for HSP parameter passing.