Table of contents
- What is single sign-on and how does it work?
- What providers are available?
- What are the available protocols?
- What are the steps for SAML setup?
- What is the required SAML information from the customer?
- What are the steps for OIDC setup?
- What is the required OIDC information from the customer?
- How does new user provisioning work?
- How does role and permission assignment work?
- How does de-provisioning work?
- What if I am an existing customer with existing users?
What is single sign-on and how does it work?
Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials -- for example, a username and password -- to access multiple applications.
At this time, Single Sign-On is only available for customers of the ProcessUnity Global Risk Exchange. If you do not see the answers to your questions, or you are still having issues with setting up Single Sign-On, please reach out to us at exchangesupport@processunity.com
What providers are available?
The Global Risk Exchange uses Auth0 as our authentication and authorization provider.
What are the available protocols?
SAML
OIDC
What are the steps for SAML setup?
- ProcessUnity will provide four values:
- Entity ID: urn:auth0:cybergrx-production:COMPANYINFO
- ACS URL (also called Post-back URL): https://auth.portal.cybergrx.com/login/callback
- Signing certificate: located at https://cybergrx-production.us.auth0.com/pem?cert=connection (customer should download it) if signing requests can be enabled.
- Signing algorithm: RSA256
- Signing digest: SHA256
- Protocol binding: HTTP-POST
- Metadata with connection name: https://auth.portal.cybergrx.com/samlp/metadata?connection=COMPANYINFO
- Customer provides metadata to ProcessUnity .
- ProcessUnity finalizes enterprise connection.
- Customer assigns their own users the new application.
- Test connection.
- Optional: If customer wants to enable IDP-initiated authentication, ProcessUnity enables it.
What is the required SAML information from the customer?
Sign In URL
- The URL where SAML authentication requests are sent. This is also called the single sign-on (SSO) endpoint.
X509 Signing Certificate
- The public-key certificate required by the SP to validate the signature of the authentication assertions that have been digitally signed by the IdP. Auth0 accepts the .pem and .cer formats.
Additionally, the customer should provide their SAML attribute mapping so that ProcessUnity can make sure any differences are accounted for to map first name, last name, and email correctly.
What are the steps for OIDC setup?
- ProcessUnity provides callback URL- https://auth.portal.cybergrx.com/login/callback
- Customer creates application in their idp and provides openid-configuration URL and application/client id
- If using the authorization code flow the customer must provide the client secret as well
- If using the implicit grant flow, the application must enable implicit/hybrid flow and id token grant type
- Customer assigns their own users the new application.
- ProcessUnity creates enterprise connection
- Test connection
What is the required OIDC information from the customer?
- Openid-configuration URL
- Application/client id
- Authorization code flow: during setup the client secret must be shared with ProcessUnity Global Risk Exchange and PKCE should be enabled.
- Implicit/hybrid flow: during setup application needs implicit/hybrid flow enabled and id token grant type
How does new user provisioning work?
The user is provisioned on demand by your IDP. Any new SSO users are given Read-Only user role by default. If you wish to configure them with additional roles and permissions, please see below:
How does role and permission assignment work?
Roles and permissions are managed inside of the platform by users with admin or manage roles permissions. You can refer to the Understanding User Roles article for more information about roles.
How does de-provisioning work?
Once configured with SSO, your IDP is in control of Authentication, if you de-provision access the user will no longer be able to authenticate in our platform. If you wish to do additional remove authorization, you can deactivate their account using the user management pages in the platform.
What if I am an existing customer with existing users?
- If the user had an account with the same email and is moving from username+password to SSO, their old username+password account will be marked as inactive. The old account can be reactivated by the platform and will not be marked inactive automatically with following log-in.
- If the user had an account with the same email and is moving from username+password to SSO, they will inherit the roles of that account. This is only performed when the user is associated to the organization for the first time, so if the original user is updated the changes will not take effect on the SSO user.