What is Single Sign-On (SSO)?
SSO gives your users an alternative way to login to their Pentana Risk application, using their business credentials. Users will only need to remember one set of login credentials to access several applications, reducing the number of ‘forgotten password’ issues.
What are the advantages of using SSO?
Users will only need to use one set of credentials to access many systems, reducing confusion with usernames and passwords for Pentana Risk and support requirements for login issues. As those credentials will be managed by your internal systems, you can also ensure that they meet your password management policies.
How does the Pentana Risk SSO work?
Once everything is configured the SSO utility is accessed via any link or the SSO login URL. Users wanting to login with their Pentana Risk credentials can still do this by going to the usual login page directly (https://<your site name>.pentanarpm.[uk/us]/login).
When a user tries to access Pentana Risk via the SSO URL address, a chain of events is triggered:
- The SSO configuration redirects the access request to your internal identity provider (IdP). The user is directed to your identity provider login screen.
- The user logs into the IdP, using their email address and password.
- The IdP confirms whether the login is correct and, if it is, passes the email address back to Pentana Risk.
- The email address is checked against the users in the system, and if there is one user account with this email address they are logged in.
- If the access fails at any stage, the user will not be logged in to Pentana Risk and the error will be logged in our system.
As the user authentication is handled by your IdP, our systems do not access any sensitive information.
What do we need to configure SSO?
To implement SSO, a relationship must be created between your Pentana Risk site and your identity provider by creating a relaying party or another type of association. To do this, you will need:
- An IdP system which can be configured in this way (ADFS, Azure AD, Google IdP, Shibboleth etc) and which supports SAML 2.0.
- A public encryption certificate (which may be self-signed) which is used to authenticate the process.
This configuration will involve modifying IT systems configuration, so we will need to work with a member of your IT team to configure SSO.
What do we do to get access to the SSO integration?
Please contact your account manager to discuss this further. If you have any further technical questions please reach out to the Support Team at firstname.lastname@example.org.