Single Sign On (SSO)
When using SSO your users along with the login credentials are all managed outside of risr/advance
SSO information
risr/advance can integrate with a customer’s SAML 2.0 single sign on. In this case users will authenticate through the customer’s identity provider (IdP) and not directly through risr/advance.
When a user successfully authenticates through the IdP they are passed through to risr/advance along with specific attributes about that user. The attributes that risr/advance needs at a minimum are First Name, Last Name, Email Address and a Unique Identifier. When a user which does not currently exist within risr/advance authenticates through the IdP risr/advance takes these attributes and uses them to create a new account for that user. It is up to the customer and the IdP to control which users should have access to risr/advance and which should not.
When a user is authenticated the IdP specifies the lifetime (max time) for which the session between the user’s browser and risr/advance should be valid. Once this time period expires the user’s session will no longer be valid and the user will be logged out. risr/advance sets a default value for 8 hours, if the value coming from the IdP is less than this then this is used instead.
Alongside the session lifetime there is also session inactivity. The IdP sets a session inactivity time value per application that the user is authenticated for. Every time a user is actively using risr/advance they are making periodic requests to the server. If no activity occurs within risr/advance for the duration of the time period set as the session inactivity then the user will be logged out by the IdP.
How to setup SSO
Our metadata can be found at:
For our UK and EU customers: https://kaizenep.com/sp/shibboleth
For our Australian customers: https://au.kaizenep.com/sp/shibboleth
For our Canadian customers: https://ca.kaizenep.com/sp/shibboleth
In order to complete the setup process we will need:
Your metadata
An agreement on which constant and unique attribute we can use to identify a user. Usually it is eduPersonPrincipalName (urn:oid:1.3.6.1.4.1.5923.1.1.1.6)
An email, usually urn:oid:0.9.2342.19200300.100.1.3
We can also use other attributes, for example givenName urn:oid:2.5.4.42 or surname urn:oid:2.5.4.4
Once we have received the above information and setup this configuration we can perform test logins to ensure it's working as expected. This is done away from the live instance through the following steps:
Accessing a link unique to your organisation (https://auth.[region].kaizenep.com/test/saml2/[org_ID])
Entering login credentials
Determining whether the resulting status page shows a successful test login and providing us with a screen shot. This will help us validate whether all the correct attributes are being passed through
Once we have validated the test login is successful we are ready to provide the SSO login link directly onto the live instance when it is appropriate to do so.
Login page
Once SSO is enabled it is possible to choose whether to allow users to login through:
SSO only
SSO and/or local credentials
It may be important to retain the option to login through local credentials if you need to allow access to external users who do not have accounts with your SSO provider.
The login screen will display login options according to the option you choose. The text shown on these login buttons can be customised.
A user must be assigned their specific SSO ID login credential for the SSO login process to function