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. Read more about these improvements and many others in the following sections.
What is new in 5.3?
GDPR compliance
Safewhere Identify 5.3 marked an important milestone that the product now fully complies to GDPR.
User consent
Flexibility of the new user consent feature allows for configuring whether consent should be asked before saving any data to Safewhere Identify’s database or before issuing any data to your applications. In addition, it allows for customizing all text on the UI to specify what data to collect and what the motivation is.
Log clean up
To support GDPR’s log retention requirement, the new log clean up feature supports for scheduling background jobs that cleans up expired data periodically. You can configure how long log data should be kept and at what time of the day the background job should run to delete expired data.
SQL Server as a log store
While Safewhere Identify has support for logging a lot of data to SQL Server for long, in version 5.3 we add support for SQL Server log store for all type of logging. It is essential to note that using SQL Server as the log store is required for all the other GDPR-compliant features.
Please note that because Identify logs a lot of data, this log store can potentially grow up rapidly. We recommend that you use the Log Filtering feature and Log clean up feature to restrict what log data you want to log and how long you want to keep them in database.
Reporting
There are two new reporting features built in Safewhere Identify 5.3. The first one is for end users who can view history of his or her consents given to Identify and applications.
The second one is integration to 3rd tool such as SQL Server Reporting Services that you can use to generate custom reports, export to supported file formats and send out to target audiences eventually using its Email subscription feature. You can find more instruction in this article.
Log filtering
Using log filtering feature, you can configure what events you want to log or what you want to ignore. The ability to filter log events can help not only GDPR customers, but also ones who want to use it to reduce the amout of logged data to save bandwidth, storage cost, and efforts to clean up redundant data.
More features for Safewhere Admin
Safewhere Identify was shipped with the new Safewhere Admin UI from version 5.2 and in 5.3 we have added a bunch of new features. The most important ones include UI for new consent feature, more advanced settings for all connectors, and new logging settings.
Breaking changes
The following breaking changes happened when we implemented new features or fixing important bugs.
New requirements for software
Safewhere Identify 5.2 from build 5.2.0.5001 and Safewhere Identify 5.3 need some latest software installed:
- .NET core 2.1.1
Please refer to this link for more detail as well as download it.
Fixed: Claims transformation pipeline sometimes leaked claims between applications
This subtle bug happened when an Identify instance has two or more applications and the first application has a Scripting Transformation attached while the second application doesn’t. The bug was that claims added to a token for the first application by the Scripting Transformation also appeared in a token for the second application. We have fixed the bug for version 5.3.
Email using for resetting password is now case-insensitive
Before version 5.3, email using for resetting password was compared using now case-sensitive comparison because it was considered a claim value. However, feedbacks from our customers showed that using case-insensitive is the right way to do.
Consent settings and consent data
In order to support a consent feature that meets GDPR requirement, we had to introduce many new settings. As a consequence, data that is now obsolete is:
- Setting: The user can choose to let the consent apply for all future logins.
- Setting: The user can choose to show option to allow consent for all additional claims.
- All user consents in database.
Settings for the new GDPR-compliant consent feature is put on the new Safewhere Admin UI.
If you are using the old consent feature, you can contact us for an SQL script to check if you have any data that needs to be migrated.
Custom components and Interceptors
When upgrading to a new version, it is important to rebuild your custom components such as interceptors, external generic authentication providers, and claims transformations. If you upgrade from a version prior to 5.2, you should notice that a breaking change we had to introduce in 5.2 due to bug fixes. See more detail here.
Another hidden breaking change is that in GDPR requires showing interactive IU to users to ask for their consents, we had to refactor runtime pipeline which affected how interceptors are handled. You can read https://github.com/Safewhere/Safewhere-Identify-samples/blob/master/Extensible%20Identify/docs/Interceptors.md for details about how to implement an interceptor the right way. If you are using an interceptor and also plan to use the new GDPR’s consent feature, updating your interceptor is mandatory. Even if you don’t plan to use the new GDPR’s consent feature, we strongly recommend you read the guideline and test your interceptor extensively.
Only Safewhere Cloud
Forms-based authentication and user dashboard
Forms-based authentication and user dashboard are two great new features that Safewhere Cloud 5.3 has. With user dashboard, your users have a single place where they can see the all applications that they have access to. More importantly, the users can click on each applications to seamlessly login to them, thanks to SSO.
And what if some of your applications don’t support one of the SSO protocols yet? In other words, users will need to enter username and password to the applications’ login pages to login? That is when forms-based authentication can be handy. The feature can simulate SSO for the users by securely storing users’ credentials and submitting them automatically without requiring users’ interaction.
Breaking changes
New requirements for software
Safewhere Cloud 5.3 and 5.2 need the following software installed:
- .NET core 2.1.1.
- .NET framework 4.7.1.
- Elastic Search, Log Stash, Kibana 6.1.0.
Known Issues
Following are known issues you may encounter with this version, please access the corresponding link to see detail description as well as possible workarounds for them.
- 56398 AutoHRD does not work
- 56785 The endpoints at openid-configuration are wrong when the Entity ID setting at the system setup is customized
- 61043 [MongoDB IdentifyAdmin] Exception thrown when creating new OAuth2.0 protocol connection
Update
Safewhere Identify version 5.3.0.5237
Identify build 5.3.0.5237 that was released on 15 March 2019 that has the following changes:
- Fixed: Identify creation is failed when using the AzureSQL.
- Fixed: It is unable to change password using reconfiguring tenant.
- Fixed: Upgrading a normal Identify tenant is broken when the previous upgrade has isDeploySafewhereaAdmin set to True.
- Fixed: Cannot load Hangfire job after upgrading Identify instance to a new version
- Fixed: Unable to update user if Email claim is not assigned in System Setup.
- Fixed: Exception thrown when creating new OAuth2.0 protocol connection with MongoDB
- Fixed: The unique email address value check is not working correctly
Safewhere Admin version 5.3.0.23
Safewhere Admin build 5.3.0.23 that was released on 15 March 2019 that has the following changes:
- Fixed: User is not logged out when the browser is closed.