Single Sign On (SSO)
P6 Auth uses SSO Connections to define provider specific configuration for authentication and user provisioning.
One or more SSO Connections may be created for a single Platform 6 Instance. Each SSO Connection has a name and SSO Connections are always listed in name order.
An important attribute of an SSO Connection is the
Login Context (URL). This URL allows the Platform 6 Portal Login page to identify which SSO
connect using... buttons to display to the user.
For example, if my organisation is allocated a custom login context of:
https://mybiz.portal.amalto.com then this URL will be used to find all SSO Connections defined with this as the
The SSO Connections found will be used to display the SSO connection button(s) on the login page.
By default, the display of SSO connection buttons will disable the display of the standard Amalto username/password login fields.
This behaviour can be overridden using the json attribute
allowSSOAndBaseLogin: true for the defined client section in the portal_config.json file.
Each SSO Connection has a
Connection Type attribute which may be set to either:
- OIDC (Open ID Connect): https://openid.net/connect/
- SAML (Security Assertion Markup Language): https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Currently only OIDC is supported.
The SSO Connection details form is available from a tab of the Administration menu in the Platform 6 Portal:
A user requires the following permissions to use the SSO Connections configuration:
sso=read (to list and review the SSO Connections)
sso=edit (to add and update SSO Connections)
sso=delete (to remove an SSO Connection)
Disabled SSO Connection¶
If an SSO Connection is not enabled (disabled) it will still be shown on the associated login page but will not be selectable:
OIDC Connection Type Properties¶
OIDC property values will vary depending upon the authentication provider being used. It is essential these values match those defined by your provider.
A good tool to validate low level OIDC configuration is: https://oidcdebugger.com/
|oidc.provider.url||Mandatory. The root context used to discover all other OIDC configuration. We wil append
|oidc.client.id||Mandatory. Provider allocated. It is typically a UUID|
|oidc.authorize.request.scopes||Mandatory. Space separated OIDC defined values, typically
|oidc.provider.tls.trustany||Optional. Set to true to disable TLS/SSL certificate validation on provider endpoints|
|oidc.client.secret||Optional. Provider allocated. Not always required but must match provider configured value|
|oidc.token.signature||Optional. Signature type used to sign OIDC id_token. One of: NONE, RS256, HMAC (default: RS256)|
|oidc.email.claim||Optional. Claim set attribute to inspect for email address to use for auto provisioning, if the
|oidc.claim.string.match||Optional. A string claim set attribute that must be present and who’s value must match the given value otherwise authentication will be denied. (format: key=value)|
|oidc.claim.stringlist.match||Optional. A string list claim set attribute that must be present and contain all the values given. (format key=value,value,…)|
In addition to the above, the provider requires the prior registration of the following:
- Redirect URI: This value should be set to the
Login Context (URL)specified on the SSO Connection
It is possible to use the optional claims match properties to restrict access to only a subset of SSO users. Claims matching is a mechanism whereby P6 Auth will check an SSO users claim set when they attempt a login. If the specified (String or StringList) claim set values do not match the configured and expected values, authenticated access is denied.
Some OIDC providers allow the administrator to add custom claims to a user. This will vary depending upon provider. However, consider the example of adding a users department name to their claim set and only allowing users from that department access to Platform 6. By adding the following property this could be achieved:
- oidc.claim.string.match: dept=procurement
Another example when using Microsoft Azure as your provider is to enable group membership claims. To activate this you need to add the following to the application manifest of the Platform 6 App definition using the Azure portal:
Next you need to identify the OID of the group you wish to restrict access by. As an example, consider we created an Azure User Group called
platform6 and an OID of: ec6d1489-b580-4078-a536-89d1e63126ad
Adding the following claims match property will restrict access to only those users in the platform6 group:
- oidc.claim.stringlist.match: groups=ec6d1489-b580-4078-a536-89d1e63126ad
Auto-provision will automatically add a P6 User if one does not exist when an SSO user first logs in. It will use an email address identified in the claim set as the P6 User email.
If a new user is created, they will be assigned the permissions specified on the SSO Connection.
P6 User Email Identification Using Claim Set
A users email is determined by examining the claim set provided by the SSO provider. The email is generally available in the claim set if the property oidc.authorize.request.scopes contains
This value should be set to
upn when interacting with Azure Active Directory users
SSO Provisioned User Indicators¶
When listing users using the Administration menu, P6 users that have been created as the result of SSO provisioning will appear visually different to other users as they will be displayed with the SSO ‘badge’.
Provider Integrated User Provisioning¶
Provider integrated user provisioning is not supported in the current version of Platform 6