Skip to content

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.

Authentication

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 Login Context. 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.

SSO Login Two

Note

This behaviour can be overridden using the json attribute allowSSOAndBaseLogin: true for the defined client section in the portal_config.json file.

SSO Login One

Each SSO Connection has a Connection Type attribute which may be set to either:

or

Currently only OIDC is supported.

The SSO Connection details form is available from a tab of the Administration menu in the Platform 6 Portal:

SSO Connections

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:

SSO Login Three

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.

Note

A good tool to validate low level OIDC configuration is: https://oidcdebugger.com/

Property Name Description
oidc.provider.url Mandatory. The root context used to discover all other OIDC configuration. We wil append /.well-known/openid-configuration to this URL to request provider configuration.
oidc.client.id Mandatory. Provider allocated. It is typically a UUID
oidc.authorize.request.scopes Mandatory. Space separated OIDC defined values, typically openid or openid email
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 email claim set attribute is not found.
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,…)

Provider Configuration

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

Claims Matching

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:

"groupMembershipClaims": "SecurityGroup",

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 Provisioning

If selected, 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 email However this is not always the case and you may need to specify an alternative claim set attribute to use if the email claim is missing or empty. The following property is used to specify the claim set attribute to use in this case:

  • oidc.email.claim

Note

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’.

SSO User

Provider Integrated User Provisioning

Warning

Provider integrated user provisioning is not supported in the current version of Platform 6