Safewhere*Identify is a new kind of user identification and administration service, providing externalized and seamless authentication and authorization across organizations.

Safewhere*Identify allows an organization to handle user identification and administration centrally and externally to all web applications and web services. Safewhere*Identify allows you to support basically any kind of authentication due to its modular and open nature and it supports many authentication methods “out of the box”. Apart from built-in methods for authentication such as username and password, it also supports all the popular authentication methods, including:

• Social logins from Facebook, Google, Twitter, LiveID, OpenID,LinkedIn
• Two-factor authentication using one time passwords and Device Code authentication
• Federation protocols including SAML 2.0, WS-Federation, OpenID Connect, and OAuth 2.0
• Generic Provider that allows you to easily create your own authentication provider.

Among the many other unique properties of Safewhere*Identify are its multi-instance architecture that allows you to effectively run many separate federation servers on the same hardware, its ability to handle multiple logins (Multi SSO), and its support of performing intelligent home realm discovery.

This new release includes a host of incremental improvements as well as several important new features. The most important of these being:

• Support of the HM role as defined by the eHerkenning and Idensys specifications used for eID in the Netherlands.
• Support of the “Profile” concept that offers the ability to let Identify and SAML 2.0 connections perform profile-specific requirements.
• Full support for SAML 2.0 Artifact binding.
• New ActAs authorization controls that makes it possible to control authorization for the ActAs functionality at the connection and user levels.
• Identify*Runtime is now shipped with a new, modern and responsive theme.
• It is now possible to generate refresh tokens and access tokens by using Identify*Admin to consume the REST API.

You can find more information about these improvements and many others in the following sections.

eHerkenning profile 1.9 and DigiD4
We are constantly looking to extend the number of local and global SAML 2.0-derived standards, connections and authentication methods. In the same way as we support e.g. the Danish eID standards such as NemLog-in for federation and NemID login, we have extended with some popular Dutch standards.

Thus, Safewhere*Identify 4.3 now fully supports the HM (broker) role that is specified by eHerkenning specifications at https://afsprakenstelsel.etoegang.nl/display/as/Interface+specifications+DV-HM+1.9 and https://afsprakenstelsel.etoegang.nl/display/as/Interface+specifications+HM-AD+1.9.

In addition, Safewhere*Identify has support for the DigiD profile that is described at https://www.logius.nl/fileadmin/logius/ns/diensten/digid/koppelvlakspecificaties/Koppelvlakspecificatie_SAML_DigiD4_v3.2.pdf

SAML 2.0 Profile Concept
SAML 2.0 is a huge specification with numerous options from which organizations build their own derived specifications. Each derived specification usually contains their own ideas about what is required, what is not, and what must be validated.

In order to cope with those specific requirements, Safewhere*Identify now introduces the “Profile” concept. When a specific profile is selected for a tenant or a connection, Identify will apply profile-specific processing code for it.

The two profiles that are supported out-of-the-box in Identify v4.3 are OIOSAML and eHerkenning. As a side note, choosing “OIOSAML” profile will not be different from choosing the “None” profile since most of the default behaviors actually follow OIOSAML specification.

Security and Usability Improvements for Identify*Admin
Although Identify*Admin is usually put behind a reverse proxy and is also protected with additional security measures in addition to the fact that only a few system administrators will in reality be provided access to it, we also verified it against all the top ten of OWASP’s security issues.

Some of the many other usability improvements for Identify*Admin include:

• Select all check box for connection dependencies.
• Showing validity period of each cert on each connection on the connection list.
• Shows information about the connection when hovering mouse over each item in the connection dependency list.
• Show Identify user’s certificates in the user detail view.

New Theme for Identify*Runtime
Identify*Runtime is now shipped with a new theme that is powered by the Bootstrap framework and Html5 Boilerplate.

The new theme has two advantages over the old one. First of all, it is a more modern design and supports responsiveness out of the box. Secondly, it supports the possibility to display the Identity Provider selection list next to a login screen of the most commonly used login method.

Identify*STS

New Act-As Authorization Controls
Safewhere*Identify now supports authorization and validation checks before issuing the ActAs token. There are validation rules that apply for both local users and AD users.

For local users, Safewhere*Identify allows per-user authorization for ActAs on the user detail page. With this control, it is possible to select which services the user can do ActAs for.

For both local and Active Directory users, Safewhere*Identify allows per-request authorization pipeline for ActAs on the WS-Trust connection. With this control, it is possible to select a set of authorized claims for each connection. A user may negotiate for the ActAs security token if he or she has a least one of the authorized claims.

IssuedTokenSymmetricBasic256Sha256 Endpoint Improvement
This is an extension of the Identify*STS endpoint IssuedTokenSymmetricBasic256Sha256, which allows the exchanged token to be run through the authentication connection’s pipeline before issuing a new security token.

There is an option on WS-Trust connection called “Allow running authentication pipeline for IssuedTokenSymmetricBasic256Sha256 endpoint”. When it is enabled, Identify*STS will try to look up authentication connection at the exchanged token’s issuer. If such a connection is found it will run the exchanged token through own pipeline before passing it on to the protocol connection’s pipeline.

Identify*STS Improved Error Handling
Identify*STS is now able to handle most of the error happening while processing a security token issuing request. With this improvement, the client will no longer receive a FaultException with message “The server was unable to process the request due to an internal error”.

When an exception is thrown, Identify*STS will make sure to the following:

• All errors are logged with detail message, error code and full stack trace.
• Fault exception response to client will have specific message with its fault code.
• All uncaught exceptions are handled.

REST API Improvements
The focus for REST API in version 4.3 has been that of stability and usability.

The biggest obstacle of using the REST API used to be the need to setting up of OAuth2 connection, clients and other settings to get an access token. This is no longer the case! It is now possible to generate refresh tokens (a.k.a. API keys) from Identify*Admin. In addition, we improved the existing API with better and more validation rules, better code and better status code standardization which has markedly increased the stability of the API.

Last but not least, a paging functionality has been added to the User API as to improve the performance of third party solutions when using the APIs.

Extensibility
Since one of the design goals of Safewhere*Identify is to provide a great deal of customization and extensibility, version 4.3 has continued this goal by providing a few new important extension points, such as custom security store resolver, custom sub resolver, custom SOAP binding, and custom AuthnRequest.

Custom Security Store Resolver and Sub Resolver
The custom security store resolver and sub resolver provide the extension points needed to plug in custom code that can handle any kind of KeyInfo found in a SAML 2.0 message.

A KeyInfo element contains information about a security key (a.k.a. a certificate) that is used to sign or to encrypt a message. One of the steps of processing a SAML message is to look up the certificate from a store by using the KeyInfo. Until now, Safewhere*Identify has and will support resolving certificates in the Windows Certificate store, whose corresponding KeyInfo contains direct information about the certificate, e.g. X509Data, Subject, or Thumbprint.

From version 4.3, a new extension point allows for plugging in custom resolvers to handle other types of KeyInfo such as indirect KeyName or no KeyInfo. In addition, it is now possible to write a custom resolver that looks up certificates from a database or other sources than the default Windows Certificate store.

Custom SOAP Binding
Safewhere*Identify supports a variety of SOAP endpoints such as assertion resolution service, SPML service as well as the ability to call SOAP services provided by other parties. By default, HTTPS transport binding is used and the message body can be signed manually to ensure data integrity.

In order to meet setup requirements in which other bindings – for instance two-way SSL – will be used, Safewhere*Identify supports new settings on Identify*Admin UI that can be used to customize bindings for all services. All you need to do is to enter the WCF XML configuration for a binding or choose one from the library for some of the most popular bindings that comes with Identify v4.3.

Customize AuthnRequest to an Upstream IdP
A typical SAML 2.0 SSO flow has an AuthnRequest sent to an upstream IdP. A new scripting setting will allow a chance for writing custom C# code to modify the AuthnRequest before it is sent to the IdP.

This setting can help solve situations in which a specific IdP requires that some of the AuthnRequest’s attributes must be set.

SAML 2.0 Artifact Binding
In addition to the Redirect and Post bindings, Safewhere*Identify 4.3 now include full support of the Artifact binding for SSO and SLO. This includes:

• Sending AuthnRequest, Response, LogoutRequest, LogoutResponse to another party using Artifact binding.
• Receiving AuthnRequest, Response, LogoutRequest, LogoutResponse from another party via Artifact binding.

SAML 2.0 Disable RelayState Validation
By default, Safewhere*Identify validates if the relaystate length does not exceed 80 bytes, which is the maximum length of the relaystate in the SAML 2.0 standard.

However, this rule isn’t enforced by several SAML implementations, which are consequently sending messages with a longer RelayState. For situations in which asking the wrongful party to fix its implementation is not an option, this new validation switch might come in handy.

SAML 2.0 BootstrapToken for ClaimsPrincipal Support
This new setting will make sure Identify sets the SAML token it receives from an upstream IdP to the BootstrapToken property of a ClaimsPrincipal. One use for the BootstrapToken is that it can be used by one of the claim transformations to call another service to fetch more claims.

Improvements for the Two-Factor Module
The following improvements have been implemented for the two-factor module:

• It is now possible to use two connections of the same plugin type for the first factor and the second factor. For example, you can use a SAML 2.0 connection for the first factor and another SAML 2.0 connection for the second factor.
• With Identify v4.3 it is possible to configure it to skip the second factor authentication, when a claim with specific claim type exists in the incoming token.
• Support for using both identities from the first and the second factors for the issued token. In previous versions, although a user had to enter two accounts for two factors, e.g. a Facebook account and a local AD account, only one of them could be passed into the claim pipeline. In Identify 4.3, we provide the possibility to pass both identities to the claim pipeline.

Diagnostics and Troubleshooting Improvements
While previous versions of Safewhere*Identify have sufficient diagnostics logging for troubleshooting most of the runtime errors, the drawback is that toggling and collecting the logs were inconvenient, because each log was enabled in a different way and were stored to a different location.

Version 4.3 takes a first, yet important, step towards improving the situation by allowing all the diagnostics logs to be configured via Identify*Admin UI. In addition, all log folders for Identify*Admin and Identify*Runtime are now placed in the same folder of the tenant.

In addition, Safewhere Event log can be shown in the Source field of a logged item name of the tenant from which it is logged. This is a big help in deployment in which multiple tenants are running on the server.

Other Minor Improvements
The default value which is set to the Subject Confirmation Data Recipient attribute of a Saml 2.0 response has been changed from a Service Provider’s entity identifier to its AssertionConsumerService.Location value.

Identify is now able to return more than one error code that is received from an upstream SAML 2.0 IdP to an SP.

We’ve worked to make Identify more lenient toward the metadata created by different systems. For Saml 2.0 connections, Identify now supports more of the standard elements that are often found in the metadata:

• AttributeConsumingService: Supports multiple endpoints.
• AssertionConsumerService Supports reading multiple endpoints. However, only the first endpoint is used at this time.
• ArtifactResolutionService: Supports multiple endpoints.
• Multiple signing and encryption certificates.

The Configurator now allows self-signed certificates to be used for SHA256 signing.

Breaking changes
For the v4.3 release, changes to System Setup settings does require IIS restart to take effect. We are working hard to remove this limitation in future releases.