Unit4 Identity Services 3.0.0 release notes
Released September 28th 2018
About this release
This release is version 3.0.0 of the Unit4 Identity Services (U4IDS). These release notes contain important information about U4IDS and provides an overview of features included in this release, important information, bug fixes and known issues.
Features included in this release
The following features are included in this release:
Multiple Identity Providers per tenant
IDS 3.0 supports setting up multiple identity providers (IdPs) per tenant. Users logging in to such a tenant will be presented with a choice of what idp to log in with. This enables organizations to allow users from different sources to log in to their systems.
A new claim login_idp is added to access and identity tokens, that clients can use to identify what IdP was used during authentication. One idp is designated as the default IdP, for configuration backwards compatibility. Clients can now send an acr_value of login_idp to optionally override and only allow one of the tenant's IdPs to be used.
Note: IDS does not attempt to identify or link users as the same person across the tenant's identity Providers. The user's subject and configured unit4_id is still used as a unique identifier and comes from the chosen idp.
Partial login
Partial login is now enabled by default. The user experience has been updated and minor improvements made to the flow. Tenants still need to opt in to allow partial login for them.
Consent and user permissions
Consent screen and user permissions screen has been redesigned. On the user permissions screen users can now revoke individual consents per client. Client applications can link directly to only the consents granted to their applications by including a clientid in the /userpermissions link.
Administration Portal
In 3.0.0 the administration portal supports the notion of tenant administrators. A tenant administrator can view or edit their own tenant configuration and add tenant specific clients, but cannot access global configuration, add new tenants or scopes. The tenant administrator persona is a system administrator at a Unit4 customer. The feature is introduced to allow for a higher degree of self service of changes to the tenant's IdP trust relationships and the provisioning of clients to access the customer's Unit4 resources.
The administrator portal supports the new feature of setting up multiple IdPs per tenant. The portal will light up with this feature when the administrator is working against a 3.0 or higher IDS.
Access Management is used to differenciate between a user's affinity to their tenant and whether she is a tenant administrator or an IDS administrator. One tenant per IDS is designated as the IDS administration tenant. Users that log on with that tenant and have appropriate rights can manage the global setup, add tenants, scopes and clients like before.
Note: External IDS admin role is regarded as a deprecated feature and will be removed in future versions of IDS
Administration API
In 3.0.0 the Administration API contains v3 endpoints, to support the configuration of multiple IdPs per tenant. Authorization now takes into account the differences between a tenant administrator and a traditional IDS administrator and their rights according to their roles.
Note: IDS 3.0.0 is the last release that support optionally running the deprecated v1 administration interfaces.
Administration SDK
In 3.0.0 the Administration SDK has gotten support for configuring multiple IdPs per tenant. The SDK is backwards compatible with older versions of IDS. Older SDK's are forward compatible with IDS 3.0.0, but cannot be used to configure multiple idps per tenant.
Note: When using older SDKs towards tenant configuration, it is the default identity provider that is changed.
Administration PowerShell Commandlets
In 3.0.0 the PowerShell commandlets can be used to configure multiple IdPs per tenant. The commandlets are backwards compatible with older versions of IDS. We reccomend to update commandlets to the latest version.
Verified IdPs
This version has been tested and verified with the following IdPs:
- SURFConext (SAML and IODC)
- Google (SAML and OIDC)
- SSO Circle (SAML)
- PingOne (SAML)
- FEIDE (SAML)
- ADFS (WS-FED)
- AAD 1.0 (OIDC)
- AAD 2.0 (OIDC)
- OKTA (OIDC)
- Id Porten / MinId / BankId (OIDC)
Note that this is not an excluding list.
Bugs fixed in this release
- Fixed: IDS Admin API support reference tokens
- Fixed: Performance of standard scope lookup during token and authorize requests.
- Fixed: Performance of .wellknown.
- Fixed: Standard scopes were listed twice on .wellknown.
- Fixed: AllowedCorsOrigins is no longer case sensitive.
- Fixed: Admin SDK default scope.ShowInDiscoveryDocument to false to avoid large .wellknown documents.
- Fixed: Nicer error message when user's have bookmarked external login pages.
Enhancements
- NameClaimType: Incorrect NameClaimType configuration is not fatal.
- login_hint: login_hint sent all the way through partial login.
- login_hint: If email is entered during partial login, it is sent as login_hint to identity provider also.
- AcrValues: AcrValues can be set on an IdP's OpenID Connect options.
- logging: Improved logging when resolving Unit4IdClaimType.
- logging: Extra logging when consent screen is to be shown to the user.
- logging: API site sends logs to Application Insights trace, not only custom metrics.
Known issues
- U4IDS does not have a feature to store SAML IdP metadata. IdP metadata must be accessible publicly on the provider site, or placed on a publically available place (e.g. DropBox, Azure Storage, OneDrive or similar).
- U4IDS no longer automatically redirect to OpenAPI documentation for API v1 in development mode. This is intentional. IDS 3.0.0 is the last release that support running the v1 administration interfaces
- Migration from v1 administration interfaces must be done on IDS 2.1 first. There is no migration solution from 1.x directly to 3.0.0.