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 number of incremental improvements as well as several important new features.

The most important are:

• The REST API supports provisioning for all Safewhere Identify domain models
• The REST API now supports SCIM 2.0 filter
• Extensive logging with ability to control log level and log source
• Storing public keys of all trusted parties in database instead of in Windows certificate store
• Support for running Safewhere Identify without Microsoft Distributed Transaction Coordinator (MSDTC)
• Support for running Safewhere Identify on the Azure environment
• Activation time for users, connections, and claims
• Various Improvements for the Security Token Service (STS) endpoint
• Improved performance

Read more about these improvements and many others in the following sections.

Support for provisioning of all domain models

The REST API in Safewhere Identify 5.0 now offers full support for all domain models. This means that you can use the REST API to provision all types of data supported Identify.

The newly added and improved APIs are:

• All connection types
• Organization
• Group
• User
• ClaimDefinition
• ClaimTransformation
• System setup

SCIM 2.0 filter for REST API

Identify 5.0 introduces a SCIM 2.0 filter (https://tools.ietf.org/html/rfc7644#section-3.4.2) for the Identify REST API that allows you to specify a filter on a GET request to narrow down your search result.

Example:

• Search for all claim definitions whose names contains “role”:
  • Filter: filter=claimType co role
  • Full GET request: https://identify-demo.safewhere.local:443/admin/api/rest/v2/claimdefinitions/.filter?filter=claimType%20co%20%22name%22

Extensive logging with ability to control the log level and log source

We have added many new types of logging to Safewhere Identify 5.0:

• Improved system log containing all runtime warnings, errors and debugging information.
• Billing log containing all details of a request and the time needed to process the request.
• Security log containing all raw SAML 2.0 messages.
• Security log containing results of validating SAML 2.0 messages.
• Revision log containing all changes made to Identify’s data.

Just as important, it is now possible to control the log level for as well as to specify where to write the log to. Learn more: here
Supported stores are Windows event log and flat file.

Storing the public keys of all trusted parties in Identify’s database

Safewhere Identify 5.0 is now storing all public keys of all trusted parties in its own database instead of in the Windows Certificate Store. This change brings a bunch of benefits:

• Gets rid of the problem of not having permission to import certificates into LocalMachine\Trusted People.
• Ensures that there is no need to synchronize certificates between nodes.
• Makes it easier to implement a management UI and a REST API.
• Makes it easier to separate certificates between tenants when deploying Identify in the cloud.

Running Safewhere Identify without MSDTC

While MSDTC is a good way to have transactions supported across databases and servers, it is sometimes a source of pain to set up. Another disadvantage of MSDTC is that it makes it impossible for Safewhere Identify to run on Azure SQL. In Safewhere Identify 5.0, we have added a new option for determining if Identify should run with or without MSDTC.

Running Safewhere Identify in an Azure environment

With the ability to run Safewhere Identify without MSDTC, we have improved the data access layer of Identify so that it now offers full support for the Azure SQL database.

Activation time for users, connections, and claims

In previous versions of Identify a connection, a user, or a claim definition could be either enabled or disabled. With Identify 5.0 we have introduced the concept of ‘Activation Time’. This feature e.g. makes it possible to publish new metadata with a new signing certificate for an Identity Provider, which will take effect in two days. This allows Identify to seamlessly switch from one configuration to another without any hiccups.

Improved STS endpoint

We have improved the OIOIDWS STS endpoint to make sure that it meets the OIO WS-Trust Profile v1.0.2 specification. All of the profile’s “MUST” requirements, including the Liberty Basic SOAP binding, have been implemented.

We have also improved the STS’ certificate and certificate mixed endpoints to support multiple certificates. In other words, when a user has multiple certificates, any of the certificates can be used to request for security tokens.

With Identify 5.0 singificant changes have also been implemented for STS logging,, especially on the billing and security logs in which you can now log full request and response messages, including their security headers, processing time and size of messages. Besides, these logging settings are configurable from the Identify admin site.

STS has further been improved to support the new features for activation time for users, connections and claims, as were described earlier.

Improved performance

We have optimized Safewhere Identify to speed up the issuance of tokens significantly, improving the performace significantly by 25% – 100% depending on the use case. That is done not only by optimizing code but also by improving the infrastructure to provide a better alternatives to SQL database usage. As a result, there are now a lot of configurable options enabling what is saved into the database and for utilizing caching, browser cookies, and NoSql, including Windows event log and flat files.

Additional changes

Two of the new improvements we have made for Identify 5.0 need additional configuration after you upgrade an existing tenant to the new version:

• Moving certificates to the Identify database means you will need to import certificates that are now in the Windows Certificate Store.. Please refer to: http://help5-1.safewhere.com/store-certificates-in-database/
• Our REST API models used to be decorated with both DataContract and JsonProperty attributes which made them inconsistent and confusing. We are now using DataContract attributes for all REST API models.
• Identify 5.0’s configurator no longer supports SQL Session state mode. Instead, we favor other options as described in: http://help5-1.safewhere.com/session-state-support/

Please refer to: http://help5-1.safewhere.com/a-comprehensive-changelog-for-identify-5-0/ for the full list of new features and improvements in Identify 5.0.