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.
Safewhere Identify 5.2.0.5015 released October 20 2018
Fix issues
- 58115 Password reset case sensitivity: email address validation should be case-insensitive when sending reset password mail
- 61326 Email address unique value issue: "user@sample.com" and "ser@sample.com" must be different when validating
New improvements
- #44172 Support NemId codefile: now the latest NemID code file JS is supported, user is no longer required Java to run to code file client
Safewhere Identify 5.2.0.5009 released August 02 2018
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.2 release?
- Support deploy Safewhere Admin from Identify Configurator
- Safewhere Admin - UI for Account linking configuration
- Account linking
Support deploy Safewhere Admin from Identify Configurator
From now, Safewhere Admin can be deployed using configurator for on-premise customers. To do that, you just need to check “Also deploy Safewhere Admin” option when creating Identify tenant. (That option will be disabled if there is no Safewhere Admin installed on Server)
Safewhere Admin will be deployed on IIS as adminv2 virtual directory under identify application. Hence, it will be accessed at https://domain.safewhere.local/adminv2/
By default, if Safewhere Admin is deployed along with an Identify tenant then it will also be replicated if this Identify tenant is replicated. In this case, if there is no Safewhere Admin installer ready on the target replication server, an error message will be shown while trying to replicate that tenant as on the following image.
When upgrading Identify, Safewhere Admin will also be forced to be upgraded using the available Safewhere Admin installer on that server. It means that, on this version, there is no option to choose whether upgrading Safewhere Admin should be executed or not yet.
When deleting Identify tenant, of course the appropriate Safewhere Admin will also be deleted.
Account linking
Account linking is a new feature which enables a use case in which you want to link users from an upstream Identity Provider to user accounts in your own user store. After a user has logged in using an upstream Identity Provider, Safewhere Identify will show an UI that asks if the user has an account in another store. If the user does have, he or she can enter credentials to confirm that and the accounts are then linked. Interaction to the second user store and how accounts are linked are customizable.
You can find guideline for how to try the feature out here.
Breaking changes
Safewhere.External.dll version was pumped from 4.4.0.0 to 5.2.0.0 because we introduced a few new types to it. This means that if your installation has custom components that rely on Safewhere.External.dll such as external claims transformation, generic authentication provider, or interceptor you need to rebuild the components.
Interface IIdentifyAuthenticationConnectionService
The interface has two new methods:
These methods are useful when you want to get an authentication connection object using its id or entity id. A typical use case is when you want to get the name of a connection given that all you have is its id.
New interface IIdentifyProtocolConnectionService
Similarly, we added an interface for protocol connection counterpart:
You can simply inject the interface to your external implementation and use it.
New interface IExternalUserCredentialsService
The new account linking needs to verify against an external store if user credentials are valid. For example, you can make a custom implementation that verifies user credentials against a REST API service.
Change to IIdentifyLogWriter
We added a new WriteDebug method to IIdentifyLogWriter that helps write debug log easier.
void WriteDebug(object message);
Change to interceptor views
If you are having a external component, for example an interceptor, that:
- Interrupts login flow with a view (UI), for example to ask a user for extra information.
- And the view then submits data to Identify to continue the login flow.
When both conditions are true, you need to add a special line of code to your view so that parameters that are required for Identify to continue the login flow are rendered correctly.
@Html.Partial("RenderFormParameters", new RenderFormParametersModel(Model.ContextId))
Notice that there is a reference to the ContextId value. We recommend that you pass the context id, which is passed to your custom code as a parameter of an interceptor, to your view model.
Example:
