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 188.8.131.5215 released October 20 2018
- 58115 Password reset case sensitivity: email address validation should be case-insensitive when sending reset password mail
- 61326 Email address unique value issue: "firstname.lastname@example.org" and "email@example.com" must be different when validating
- #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 184.108.40.20609 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 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.
Safewhere.External.dll version was pumped from 220.127.116.11 to 18.104.22.168 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.
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
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))