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.
Safewhere Identify 5.4
Identify OAuth 2.0
There are several changes on Identify Oauth 2.0 version 5.4 making it more applicable and flexible as following
- Support CORS
- Allow http redirect so desktop application can work against Identify OAuth 2.0
- Support RFC 6749 basic authentication header
- Support for using NameID’s value for the sub parameter
- Support prompt parameter with option “none” and “login”
- Enhance error handling when receiving an invalid request
Two more OAuth 2.0 client samples, which are WpfDesktopApp and JavaScript application, are also available on our GitHub repository https://github.com/Safewhere/OIDC/tree/master/src
Enhance logging on OAuth Provider
On previous versions, when receiving error response from an upstream Identity Provider, OAuth Provider did write error log respectively, but the content was not clear enough. From version 5.4, it is improved with 2 more following event ids
- 4110: is a common error event for OAuth 2.0 which may be caused by many different errors.
- 4111: is a response error event.
Authenticator as a new OTP option
In addition to SMS and Email, we added support for TOTP Authenticator. This means that a user can use any Authenticator app such as Google Authenticator, Microsoft Authenticator, or Authy. We will add support for reset and re-onboarding a user to the next version.
NemID plugin
We updated the NemID plugin to supports NemID CodeFile. We also verified that our NemID plugin works well with the NemID code app.
Logging
We continue adding more extension capability to Safewhere Identify. The new feature is the ability to feed all logs to an external log store. One example use case is that you can use a local RabbitMQ store for fast logging, and then use a custom tool to feed logs from RabbitMQ to a remote store or an analysis tool such as Azure CosmosDB or ElasticSearch.
Identify REST API
New important APIs are:
- Support full GET, POST, PUT, DELETE for field configurations. Therefore, you can use it to update password validation rule now.
- System setup. API: /api/rest/v2/systemsetup
- Correlation error. API: /api/rest/v2/correlationerror
- Authentication context method class. API: /api/rest/v2/authenticationcontextmethodclass
- Clean up session data. API: /api/rest/v2/systemsetup/cleanupsession
Security enhancement
We added a few new security enhancements:
- We provide a script to run against an IIS instance to always set the X-Frame-Options header to SAME ORIGIN to all responses. Please note that you will need to run the script every time you create a new Identify instance. We will add support to do this via Configurator in a future version.
- A new setting in System Setup where you can specify domains that allows to host Identify and Safewhere Admin in an iframe.
- A new setting in System Setup where you can specify what domains can use CORS against Identify.
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.
Merged fields for SMS
In order to be consistent with email template, the following merge fields are now supported when sending OTP code:
<%=SMSTEXT%>: OTP code
<%=SMSNUMBER%>: destination phone number to send OTP code
Hosted form
From 5.4, we have introduced a new password endpoint that receives only a single parameter: id of the in-use Username & Password authentication connection.
https://identify.safewhere.local/runtime/ResetPassword/ForgotPassword2?connectionId=guid
In addition, we updated the forgot password link used on Hosted Forms’ Login form to /forgotpassword2. If there are more than one U&P connections configured for a protocol connection, the one with higher index in the connection dependency list will be used.
Updated some dependencies to latest releases
We constantly update Identify’s dependencies to their latest version to benefit from their new features as well as security fixes. In version 5.4, we upgraded all .Net core dependencies 2.1.1. Other notable upgrades are:
- Newtonsoft.Json to version 11.0
- EntityFramework to version 6.2
- Asp.Net MVC to version 5.2.6
Safewhere Identify 5.4 bug fixes
Identify REST API
Fixed: User having Observer REST API role cannot get email servers and email templates
This bug happens on those following APIs
- GET /api/rest/v2/emailconfiguration/emailservers
- GET /api/rest/v2/emailconfiguration/emailtemplates
On previous versions, user who has REST API role as Observer cannot get list of email servers and templates.
Fixed: a bug on EmailGateway API which showed password credential information on its response
This bug happens on EmailGateway API:
POST/PUT /api/rest/v2/emailconfiguration/emailservers
There was a security bug on previous versions since it showed the password explicitly on the response
Identify configurator
Fixed: A bug on certificate importing function which would potentially cause duplicated certificates having same thumbprint on datastore.
It was able to import 2 certificates having same thumbprint to datastore which would throw exception when a tenant references to this thumbprint for its signing certificate. This is fixed in version 5.4 so now it no longer allows to import 2 certificates having same thumbprint to datastore.
Fixed: A bug which would import private key of a certificate to LocalMachine/TrustedPeople store
When using Identify Configurator on previous versions to create a new tenant and choosing to import a signing certificate from file, Identify imported the certificate with its private key to LocalMachine/TrustedPeople store.
Similar problem happened when trying to import certificate file with private key to use as SSL certificate
These bugs were fixed from version 5.4
Fixed: A bug happened while creating tenant which did not allow using password containing character "
When creating tenant using Identify Configurator, if the password contained character " the process would be stopped and throw exception. It is fixed from version 5.4.
Fixed: A bug on Identify Configurator which did not allow user to change password using “reconfigure an instance” option
A user was not able to change his password by using function “reconfigure an instance” on Identity Configurator. It is fixed in version 5.4 and 5.3
Identify Admin
Fixed: An issue which is unable to import “.p7b” certificate
On Identify Admin site, tab System setup/manage certificate, it would throw exception when trying to import p7b certificate to local DB. This bug is fixed from version 5.4.
Fixed: A bug on email address uniqueness validation function.
There was a bug on email address uniqueness validation function which did not allow to create 2 accounts having email abc@safewhere.com and myabc@safewhere.com respectively. This was totally fixed on this version.
Fixed: Unable to create new protocol connection when using Mongo DB as audit DB
This bug happened on a tenant which uses MongoDB database as Audit database. Using Identify Admin, exception would be thrown when creating some protocol connections such as OAuth 2.0, SAML 2.0 or WSFederation.
Fixed: A crash bug on Identify when Mini profiler was enabled.
Previously, there was a crash bug happened on Identify when Mini profiler was enabled. It is fixed in version 5.4.
Fixed: Passwords could be brute-forced after login
Previously, password can be brute-forced to guess what it is. That means anyone can try to enter wrong password unlimited times which would pose a threat to client’s credential security.
From this version, Identify will restrict the maximum attempts when changing password (Identify Admin, Safewhere Admin & REST API and Identify Runtime when password is expired). The maximum number is configurable on each connection (Username & Password for password expired), or default value is 10. After exceeding the maximum attempts, the user would be disabled to prevent hacker trying to guess the old password
OAuth 2.0
Fixed: wrong algorithm value shown on access token when using HMAC with key length is 48 or 64
Previously, when using HMAC, the algorithm value on access token would be
- With 48 key length, it was http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
- With 64 key length, it was http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
Which is fixed on version 5.4. So, for now, it will be
- HS384 if key length is 48
- HS512 if key length is 64
Fixed: a bug which would log SerializedClaimsPrincipal information when handling token request
When processing a token request, Identify OAuth 2.0 mistakenly logged the whole ClaimsPrincipal information to logging target. This sensitive data was removed from version 5.4
Fixed: a bug which allowed granting access token for a user whose inactive password
On previous versions, even though password was not active yet (since the password was expired or was forced to reset), a user was still able to negotiate for an access token from Identify OAuth 2.0 by using password flow. It is fixed on version 5.4 by returning a “invalid_client” error response.
Fixed: wrong url addresses used on discovery metadata if the Identify’s entityid is changed
This bug happened on endpoint https://[tenant]/runtime/oauth2/.well-known/openid-configuration
Previously, discovery metadata used Identify’s EntityId as domain for all the other endpoints including authorization endpoint, token endpoint and so on. Therefore, all the addresses would be wrong if Identify’s EntityId is changed. It is fixed on version 5.4.
Fixed: a bug which allowed attacker to get a valid access token from OAuth 2.0 endpoint
This bug could happen on SSO flow having UI interceptor. When being redirected to interceptor page after SSO flow, by alternating the return URI parameter on the OAuth authorization request to a fake site, an attacker can receive a valid access token. This is fixed on version 5.4.
NemID plugin
Fixed: a security bug on NemID authentication’s consent page
There was a security bug where replaying the collected ici_ci parameter at the NemID authentication’s consent page can inject its data to another authentication’s approved consent data. It is fixed on version 5.4.
Others
Fixed: a crash bug when sending correlation error
Previously, crash bug was thrown when user was trying to send a correlation error. Besides, corresponding error saved on database also involved incorrect encoded html characters. All those problems are fixed in version 5.4 already.
Fixed: there were lots of redundant log message
Previously, when enabling DEBUG mode for Admin components, there were a numerous redundant log messages as “Thread.CurrentPrincipal is of type System.Security.Claims.ClaimsPrincipal.”. All of them are removed in version 5.4.
Safewhere Admin 5.4
Logging
Provide an interface to enable an external logging service to log all entity changes made on Safewhere Admin side.
Client tab
Safewhere Admin version 5.4 provided a new option in Client Tab to native Windows application.
Application name
From this version, all the texts related to One Admin were corrected to Safewhere Admin
System setup
Several settings of system setup now are available on Safewhere Admin including
- System tab
- Field configuration
- Clean up session data
- Certificate
- Error
- Authentication context method class
- Logging
It also provides some changes such as
- More useful settings on Identity Provider and Service Provider connectors
- New setting: Allow HTTP redirect at the OAuth2.0 application and OpenIDConnect application.
- NemID connector
- Support the customization on the claim for the identity bearing claim
- Support to show some claims from Identify Admin to Safewhere Admin
- More useful settings on OTP for Google Authenticator
Identity provider and application connectors
There are a few useful settings added on Saml 2, OAuth 2.0, OpenId connect in version 5.4 such as Token Lifetime, Enable session status change notification.
New option on Identify configurator to deploy Safewhere Admin for existing tenant
From version 5.3, we already had an option on Identify configurator to deploy Safewhere Admin for new tenants. It is then enhanced from version 5.4 to either support deploying Safewhere Admin for existing tenants. Please refer to http://docs-v1.safewhere.com/identify-deploy-safewhere-admin-for-existing-identify-instances/ for a complete guideline. Another important note is that from this release we will ship both Safewhere Identify and Safewhere Admin in a single installer file.
Supporting using text resource on html templates on Safwhere Admin
With an arm to enable displaying multiple languages on html templates on Safewhere Admin, from version 5.4, it allows adding @Resources.Runtime.XYZ to render the corresponding text. Please refer to http://docs-v1.safewhere.com/identify-how-to-use-text-resource-on-html-template-on-safewhere-admin/ for a more detail.
Bug fixes
Fixed: a whole host of UX issues
There were several UX problems fixed on Safewhere Admin version 5.4, some of them are listed below
- Enhanced the appearance of title on each resources list
- The claims were overlapped on setting page of the mapping claim transformation
- The options list on user advanced search was broken
- Upload certificate form was not shown on Firefox
- Fixed typo mistake on Salesforce connector
Fixed: Move log folder to Safewhere Admin tenant’s folder
Previously, logs of Safewhere Admin was placed on C:\temp which is not an appropriate directory, so we moved all the logs to “Logs” folder where Safewhere Admin instance is installed. This is implemented from version 5.4
Fixed: a bug which caused that Captcha could not be loaded when using hosted form
On previous versions, Captcha on hosted forms couldn’t be loaded, but it was fixed now.
Fixed: a bug which threw exception when saving discrete claim while its option is not saved yet
On previous versions, saving a discrete claim while its option is not saved yet will throw exception. This bug is fixed on version 5.4. The unsaved option will be ignored, and the discrete claim will be saved successfully.
Fixed: a UI bug when creating new claim
On previous versions, when saving a new claim, it will be created successfully but its name is not updated properly, so it still showed “new claim” instead of the new claim’s name on the top left menu. In addition, if user tried to save it the second time, exception would be thrown. This bug is fixed on version 5.4.
Fixed: Removed username and password fields on HTTPRequestSMSGatewayConfiguration
On HTTPRequestSMSGatewayConfiguration, it showed 2 redundant fields Username and Password which should be added as parameters.
These fields were removed from Safewhere Admin version 5.4
Samples on our GitHub repository
There are a couple of new samples which work against Identify v5.4 as below
- Safewhere.External.Samples are now available on GitHub with all the documentations for interceptors
- 3 new OAuth 2.0 samples
Breaking changes
- New requirements for software: OIDC sample on GitHub needs the following software installed: .Net core 2.1.5
- For existing NemID authentication connection, the setting “OpenOces applet endpoint” (if using Identify Admin) or “Key file client URL” (if using Safewhere Admin) needs to be changed to https://codefileclient.danid.dk/ to use new NemID code file client.
Update
Safewhere Identify version 5.4.0.27
Identify build 5.4.0.27 that released on 18 Jan 2019 that has the following changes:
- Fixed: Exception thrown as cannot load Hangfire job after upgrading Identify instance to new version
- Fixed: it is unable to replicate Identify instance when it uses SQL authentication
- Fixed: The Bootstrap token is not attached although setting: Set bootstrap token for ClaimsPrincipal at the SAML2.0 authentication is enabled
Safewhere Identify version 5.4.0.30
Identify build 5.4.0.30 that released on 1 Feb 2019 that has the following changes:
- SharedConfigurableSettings API now supports PATCH method and have more properties for localized contents. In other words, from version 5.4, it is able to localize content for Help text and Error message in English (en) and Dutch (nl). More details can be found on http://docs-v1.safewhere.com/identify-how-to-localize-field-configuration-with-rest-api/. Please to be noticed that this API did not support the other languages such as Danish (dk) or English (en-us), etc yet. That means, using those language indicators would encounter error message "languageCode is invalid, expected value is one of these values: nl, en.". We are about to support all languages for this API in version 5.5
Safewhere Identify version 5.4.0.31
Safewhere Identify build 5.4.0.31 that released on 22 Feb 2019 that has the following changes:
- Fixed: User is not logged out when the browser is closed.
Safewhere Identify version 5.4.0.33
Safewhere Identify build 5.4.0.33 that released on 3 April 2019 that has the following changes:
- Fixed: more support for customer who needs out of band keyinfo.
Safewhere Identify version 5.4.0.36
Safewhere Identify build 5.4.0.36 that released on 6 Nov 2019 that has the following changes:
- Fixed: The merge fields are not extracted when using default HTTPRequest SMS gateway.
- Fixed: The issuance claim are not logged when doing the login via the STS endpoints.