This document summarizes all new features and bug fixes for version 5.13 as well as breaking changes when being upgraded from previous versions.
New features and improvements
IdentifyMe application
IdentifyMe is a new application shipped with Identify that allows end-users to update their profiles, reset their passwords, register or reset TOTP/WebAuthn authenticators. In future versions, we will add even more useful features to the application. Even though the first version of IdentifyMe does not include licensing restrictions, you will require an additional license to use it after we finish applying license protection in the next version. You will also require an updated license file to utilize the IdentifyMe application.
To learn more about what features that IdentifyMe can offer, please visit IdentifyMe - features and guidelines.
Signing certificate rollover
The signing certificate rollover feature offers a way to roll out a new signing certificate without removing the current one immediately. In short, the rollover process is:
- The current (primary) signing certificate is going to expire.
- You configure a new secondary certificate.
- All connected Service Providers and Identity Providers update their systems to reflect the fact that there are now two signing certificates in use.
- After a few days, the secondary certificate is promoted to be the primary certificate, and the former primary one is demoted to be the new secondary certificate.
- After another few days, the demoted certificate is removed from Identify.
This process ensures that there is virtually no downtime caused by rolling out a new signing certificate. You can read more about this feature at Signing certificate rollover
Use WebAuthn as a first factor authentication method
You can use WebAuthn as a first-factor login method like other first-factor authentication methods such as Username & Password, SAML 2.0, WS-Federation etc. Please refer to this guideline for how to set it up.
Forward prompt=login
to upstream OpenID Connect (OIDC) Identity Providers to re-authenticate users
When your OIDC sends a login request with prompt=login
parameter to Identify, Identify asks the user to re-authenticate. However, in the previous versions, if the user is using an upstream OIDC Identity Provider, Identify will not forward the parameter to the Identity Provider. As a result, the Identity Provider will not ask the user to re-authenticate. In version 5.13, Identify can forward the parameter correctly to upstream OIDC Identity Providers.
Update user claims on access token when calling the token endpoint with a refresh token
We supported a new Update the access token on a refresh token request setting on the Security tab of OIDC application.
By default, when you exchange a refresh token for a new access token using the OAuth 2.0 token endpoint, Identify returns a new access token but with the exact same claims as previous access tokens even if the related user's claims have changed. When the new setting is enabled, Identify will issue access tokens with latest user's claims in the database.
Note: this setting is only applicable to refresh tokens which are generated by My REST API key feature or when users log in using the Username & Password authentication connection. It does not apply to logins using upstream Identity Providers.
Step-up support for OIDC plugin
We introduced the Step up feature in version 5.5, but there was no support for the OIDC plugin yet. The step-up feature now works for the OIDC applications via the acr_values parameter:
1 2 |
acr_values OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2. The acr Claim is requested as a Voluntary Claim by this parameter. |
Correct EDMXCache folder permission on Identify Admin/Runtime
This improvement is relevant if you usually need to deploy custom assemblies to Identify Admin and Runtime's bin folders. All the EDMXCache folders now have correct permissions granted so you will not need to delete them after custom assembly deployment anymore.
Support index on OauthAccessToken's UserId
We added a non-clustered index to the OAuthAccessToken table to improve performance when Identify needs to look up for OAuth access tokens saved in the database using UserId.
Random string generation
We updated code to use RNGCryptoServiceProvider for random string generation in many places such as generating OAuth connection's client secrets, encryption keys etc. Please note that this is an enhancement in an attempt to make it consistent in how we generate random values rather than a security bug fix.
Password generation
When new users are created without having passwords specified, Identify needs to generate random passwords for the users. In the previous versions, if you have modified the default password regular expression, generated passwords may not satisfy the modified regular expression which forces Identify to keep retrying and ends up with an infinite loop.
In version 5.13, we improved password generator code that can generate more complex passwords without suffering the infinite loop problem.
Clean up cookies
Identify has many cookies that control its behaviors such as:
- Session cookies
- Selected authentication connection cookies
- And many more
Sometimes, due to the state of cookies, users end up at a dead end. For example, many users get the "Invalid context" error every time they access Identify, but because they are using mobile devices that do not allow them to close browsers to have all cookies deleted, they cannot proceed with logins. Even if users are accessing Identify on desktops, closing a browser instance may not be a favorable option because they have many important tabs open.
Users now can use the new Delete cookies to delete all Identify cookies.
Retire the WCF service
We retired the WCF service that was hosted at /Service
which has not received any updates for many years. As a result, the Identify Configurator tool and Configurator CLI no longer deploy the /Service application:
- Create a new instance: It does not deploy the /Service application under the Identify website.
- Upgrade an existing instance/Mass tenant upgrade: It deletes the /Service application under the Identify website if it exists.
The Identify Configurator tool also removes:
- The registered Service source in EventLog viewer.
- The deployed files under the
/identify/tenant/<schema>/service
folder. - The Service information entry of the tenant's XML configuration.
When using the Configurator CLI, the servicePool
configuration parameter is now obsolete. You do not need to specify it anymore.
Safewhere Admin
Retire the old Admin site and add missing features to the Safewhere Admin site
As communicated previously, we finally killed off the old Admin interface in version 5.13. From now on, you will need to use the new Safewhere Admin site at /adminv2
to make changes to your Identify instances. As part of this transition, we finished porting all remaining features from the old Admin site to the new one.
Merge connection settings
Originally, the new Safewhere Admin application treated OAuth 2.0 and OIDC as two separate connection types. Version 5.13 has merged them into just one connection type similar to how the old Admin site did before. The biggest motivation for the merger is that you can use Safewhere Admin to configure a connection to serve both OAuth 2.0 and OIDC clients. Similarly, Safewhere Admin can handle WSFederation and WS-Trust connections properly now.
Create Idp-initiated connection
You can now create a protocol connection that is specifically used for the Idp-initiated flow:
Show all claims for access denied user
The new Admin portal requires that users must have some mandatory claims (roles) to use it. Due to configuration issues, you might sometimes not have necessary claims and get the Access denied page shown after logging in. From version 5.13, the Access denied page now can display all claims that a logged in user has which can make troubleshooting a lot easier.
Claims that are marked as sensitive have values displayed as "*****"
A better way to select hosted forms
We made it easier for you to navigate between forms of the Hosted forms page with a faster scroll and a search box:
Ability to rename resources on Safewhere Admin
You now can rename resources directly on a resource's Edit page. Resource types that support renaming are Organizations, Groups, Claim Definitions, Claim Transformations and Connections.
Please note that you cannot rename the following system resources:
- The Identify OAuth2 Token for REST APIs application
- The Identify runtime connection application
- The IdentifyMe application
- The Root organization
Move installation and deployment folders
The Identify installer now copies Safewhere Admin v2 source to the Safewhere\Identify\OneAdmin
folder. Safewhere Admin v2 instances are deployed in the Safewhere\Identify\tenants\[tenant]\adminv2
folder. This change ensures that all Identify applications are deployed under the same folder.
Audit log viewers
The Audit logs tab has some new Audit log viewers:
- Audit correlation error
- Audit authentication context method class
- Audit approved consent
- Audit persistent pseudonym
- Audit attribute service connection
- Display the author's name who creates/updates User on both the Audit user created view and the Audit user updated view
Support uniqueness of claim value data
We added a feature to that allows you to manage constraints that ensures uniqueness of values of a free claim definition at the database layer. Even though Identify has had code to check for uniqueness at the application layer, the check does not always work due to race condition issues when multiple requests to change the same resource object come to multiple servers at the same time.
You can define unique constraints on the Uniqueness tab.
You can also create constraints using REST API:
Identify REST API
Rename a ClaimDefinition
The ClaimDefinition model now has a new optional attribute named newClaimType
. When you send a PUT request that has the newClaimType
attribute set, Identify will update name of the ClaimDefinition to the new name.
Rename a Connection / Organization / Claim Transformation / Group
The Connection / Organization / Claim Transformation / Group model now has a new optional attribute named newName
. When you send a PUT request that has the newName
attribute set, Identify will update name of the respective resource to the new name.
Author parameter on Audit user created and Audit user updated
The Audit user created logs and Audit user updated logs now have a new Author
attribute that tells who made changes users that caused those event logs.
- Audit user created
- Audit user updated
A bunch of new Audit endpoints
We added new REST API endpoints that you can use to get audit logs of:
- Audit correlation error
- Audit authentication context method class
- Audit approved consent
- Audit persistent pseudonym
- Audit attribute service connection
Breaking changes
When upgrading Identify instance from a previous version, you may experience some changes:
5.13 REST API change
You can find new changes on 5.13 APIs here.
Upgrade .NET core runtime to .NET 6
We upgraded .NET core runtime that Identify needs from 3.1 to 6.0. You must install the Hosting Bundle package prior to installing Safewhere Identify 5.13. At the time of writing, the latest release was 6.0.8.
Retire the WCF service
The WCF service is totally retired from version 5.13. For the very few customers who are still using it, migrating your client applications to use the REST API is recommended. The REST API is much easier to use and has many more features.
Retire the old Admin interface
The old Admin interface is no longer available. This means that you will need to use the new Admin interface at /adminv2
to manage your Identify instance.
Known issues
- You cannot onboard the platform authenticators on incognito or InPrivate browsers
- Registration and authentication are not supported for iOS > 15. You have to use Safari 14.
- Firefox does not support the count-down pop-up when onboarding the OTP.
- You must reset IIS to apply the logging settings and IdentifyMe connections.
- Some claims' value is not hidden although its 'Sensitive claim' is True.
Bug fixes
- Fixed: #83879 [REST API][Field Configuration] System.NullReferenceException happened on the Manage certificate page when creating a Field configuration without ResourceKey via REST API.
- Fixed: #85218 [SWAdmin] The textarea can be dragged out of the form
- Fixed: #85392 [SWAdmin] The Owner organization filter does not work with pagination page on the Group list and User list.
- Fixed: #86339 [SWAdmin] Update text label from 'Entity id' to 'User id' on Audit user created / Audit user updated.
- Fixed: #87084 [SWAdmin] The audit logs type drop down is not sorted.
- Fixed: #87176 [SWAdmin] The user claims are filtered when creating a new user with 'Send password email to user'.
- Fixed: #87491 [SWAdmin] Correct a typo on validation message on the User page when email of a newly registered user already exists.
- Fixed: #87255 [SWadmin] The Application/Identity Provider form sometimes shows loading icon after user reauthentication.
- Fixed: #85187 [IC/CLI] Deleting a tenant returns an error when its application pool was deleted by mistake.
- Fixed: #86197 [Passive] Identify Session is not removed after accessing SP and Identify which returns a Responder error
- Fixed: #86463 [SWAdmin Logging] The Date should be the first column
- Fixed: #86924 [SWAdmin] Able to create users with the same name claim
- Fixed: #84393 [Logging] Errors related to cryptographic performance counters log on Application Insights.
- Fixed: #87864 [SWAdmin] User mass update status is failed when the selected user does not have Name claim
- Fixed: #85341 [STS] Object reference not set to an instance of an object has returned when
Allow runing authentication pipeline for IssuedTokenSymmetricBasic256Sha256 and IssuedTokenMixedSymmetricBasic256Sha256
is enabled and its equivalent Identity Provider does not use Name claim as its identity bearing claim. - Fixed: #87919 [IC/CLI] The Safewhere Admin v2's clientSecret of the redudant Identify instance is base64-encoded when replicating the instance right after encrypting Identify tenant database.
- Fixed: #88140 [Runtime] The title shows OS2faktor error on OTP authentication error hosted form although the current OTP does not enable OS2facktor method.
- Fixed: #88268 [SWAdmin] Expired certificate's color is white on Select Certificate dialog.
- Fixed: #88274 [SWAdmin] Cannot create an Attribute service whose name is an URI value.
- Fixed: #88284 [Logging] the AzureClientSecret information is rendered on Audit identity provider configuration.
- Fixed: #88407 [SWAdmin] The user list shows empty when accessing page 2 of user list then choosing filtering the list based on organization.
- Fixed: #88777 [IC/CLI] Correct typo on displayed error messages.
- Fixed: #88956 [SWAdmin] Cannot clear Name claim of the User on its Edit User page.
- Fixed: #90714 [SWAdmin] Cannot upload *.crt and *.der file extensions for User certificate.
- Fixed: #90922 [SWAdmin] "An item with the same key has already been added" error displays when creating second WSFederation application without updating EntityId on first newly-created WSFederation one.
- Fixed: #91201 [SWAdmin] Support
Show the link to return to the selector page
setting on NemId / LDAP / OTP identity provider.