Single Sign-On
The platform now supports Okta and Azure AD single sign-on capabilities. This has been included to assist those clients that wish to centrally manage users access to platforms they operate in. The platform can now be added to that list.
Please see below the helper articles to assist with this setup.
General
When signing up a new user, they will need to login first with their email/password to setup their 2FA for the platform. Without the 2FA set up, they won’t be able to use the SSO login.
Adding SSO for a tenant will setup that specific tenant with SSO. So any users in that tenant can now sign in with SSO, depending on how they are setup in your specific SSO Client.
SSO In Platform
Azure
Inside the connected accounts for a tenant, we can add SSO settings for Azure. This requires the following details:
Client ID
Client Secret
Tenant ID
Okta
Inside the connected accounts for a tenant, we can add SSO settings for Okta. This requires the following details:
Client ID
Client Secret
Base URL
Setting up Azure AD SSO
Log into Azure Portal and go to the “App Registrations” page.
Click on “+ New Registration” in the top left of the “App Registrations” page
Under “Name” give the new application a unique name
Under “Supported account types” select an account type (choose “Accounts in this organisational directory only”).
Under “Redirect URI (optional)”, choose “Web” in the drop-down and enter the following URL:
https://{tenant_name}.{tenant_region}.vulnerability-platform.com/login/azure/callbackClick “Register”
You’ll be redirected to the “Overview” page of the new application
Within the “Overview” page, under the “Essentials” section, there will be an Application (client) ID which can be copied into the Client ID field in the platform, under the the Azure within the platform’s Connected Account section in the platform.
Within the “Overview” page, under the “Essentials” section, there will be an Directory (tenant) ID which can be copied into the Tenant ID field in the platform, under the the Azure within the platform’s Connected Account section in the platform.
Within the “Overview” page, under the “Essentials” section, click on “Redirect URIs”
The “Platform Configurations” section will appear
If not already populated from earlier step, enter the following for the “Redirect URIs”:
https://{tenant_name}.{tenant_region}.vulnerability-platform.com/login/azure/callback
Under “Front-channel logout” section, enter the following URL for the “Front-channel logout URL”:
https://{tenant_name}.{tenant_region}.vulnerability-platform.com/logoutUnder “Implicit grant and hybrid flows”, select the checkbox for “ID tokens (used for implicit and hybrid flows)”
Click “Save” and then return to the “Overview” page
Select the “Certificates & secrets” page from the left-hand side bar
Within the “Certificates & secrets” page, under “Client secrets”:
Choose “+ New client secret”
Within the “Add a client secret” section provide a Description and set your Expires timeframe
Click “Add”
Within the “Certificates & secrets” page, under “Client secrets”, a new entry for the client secret will appear.
Next to this new secret entry, copy the string of characters under Value. The string of characters should be copied in the Client Secret field in the platform, under the the Azure within the platform's Connected Account section in the platform.
NOTE: Do not copy the string of characters under Secret ID
Under the platform, click “Save Changes” to commit the configuration to the platform tenant. This will assign this Azure configuration to the tenant:
Within Azure, choose “API permissions” page from the left-hand side bar
Under the “Configured permissions” section. There should be a “User.Read” entry within the “Microsoft Graph” permission.
This “User.Read” permission requires admin rights. Click on “Grant admin consent for {Company}“. This is so the application is allowed to the read the user's details for signing into the platform. If this isn’t selected then the application won’t be able to sign into the platform.
Restricting Azure to specific users
The above setup will allow anyone in your organisation to login with Azure. If we want to lock it down to a specific group of users, then we can do the following:
Go to the overview page
Find “Manage application in local directory” and click on your application name, this will take us through to the application properties page.
On the left hand bar, under Manage, click on Properties.
Scroll down and there is a property called “Assignment required?” change this to “Yes”.
Click Save
Click on Users and Groups on the side panel. Here we will assign the users we want to allow access to this SSO login.
Click “Add user/Group” and select the users we want to allow.
Select the users you want to allow and press “Select” at the bottom.
This should update the page with the users selected, click “Assign” at the bottom.
You should now see the list of users allowed to use the application.
Any user not assigned to this list will not be allowed access to the SSO login, the platform will redirect them to Azure, but they will hit an error page and will have to return to the platform.
Setting up Okta SSO
After signing up to Okta, and downloading the Okta app, you will be redirected to the application page. There should be an “Admin” button in the top right, click on that.
When in the admin panel, we will need to create a new application.
In the side panel, click on “Applications”
Click “create new web integration”
Click on “OIDC - OpenID Connect” and click “Web Application”, click next, this will take us to the application page.
First we should give our app a name.
For the Grant:
Click on “Client Credentials”
Click on “Implicit (Hybrid)”
Under “Sign in redirect url” enter:
Under “Sign out redirect url” enter:
Under “Assignments” we can either allow all access to individuals in the Okta tenant, or add a group to allow specific individuals to access the platform.
Click “Save” when finished.
When we have finished setting up Okta. We need to copy a few items into the platform to setup the tenant to allow SSO.
We need the “Client ID”, “Client Secret“, and the “Base URL“.
The Client ID can be found at the top of the page on the General page of the application
The Client Secret is on the same page, just underneath
The Base URL is set when you sign up to Okta, this can be found under the pop-out of the admin page at the top right. If you click on your account name it will dropdown with the account details. It will look like “*****.okta.com”. This is used by the platform to call your specific Okta tenant for the user details when signing in. This should be prefixed with
https://, sohttps://mytenant.okta.comGo back to the platform and set up Okta under the connected accounts using the above information. This will setup SSO for the tenant.
Restricting Okta to specific users
The above setup will allow anyone in your Okta directory to sign in with SSO in the platform. We can restrict specific users in Okta using the following details:
Under the “General” Tab, scroll to the bottom to find “Federation mode”. If this is enabled, then we can disable this and setup specific assigned users.
Go to the “Assignments” tab
You should see a table and an “Assign” button. Click this and a modal will pop up with a list of users in your directory.
You can assign users here and this list will be the users that can sign in with Okta SSO.
Restricting Users using SSO in Platform
Within the platform, under the “Users” section, we can assign a flag on a user to only allow them access to a tenant when they sign in with SSO. This means that if a user signs into the platform using a traditional email/password then they won’t be able to access the tenant that they are setup on with “SSO Only”.
If a user signs in with email/password and the user is assigned to one tenant with “SSO Only”, then they won’t be able to sign into the platform, and will be shown a message on the login screen.
If the user is assigned to more than one tenant, and one of the tenants isn’t setup with “SSO Only” then they will be be allowed to sign in, but they will be restricted from accessing the tenant with the “SSO Only” rule applied.
Signing in with SSO allows access to all tenants the user is associated with.
Logging into Platform
After setting up SSO, you will be able to sign in from the login page using SSO.
When clicking the “Login with SSO” button, the user will then need to supply their email address, this will now be case sensitive and needs to match the case of the email address in the users profile. Clicking next will take us to the the platform 2FA page. When completing 2FA, the user will be presented with SSO options, depending on the SSO that has been setup for the tenants that they are associated with.
Clicking on either Azure/Okta will take the user to the respective directories. If they are successful then they will redirected and logged into the platform. If not, they will see a screen letting them know what happened, or will be redirected back to the platform.
Troubleshooting
Azure
When signing into Azure, if a user hits a page that says that the application needs admin permission to sign in then Azure doesn’t have the correct permissions. Sign into Azure and go to “API permissions” on the side bar and Click on “Grant admin consent to {Company}“. This allows the app to read the user details and send them to the platform to read their email.
Okta
If a user is trying to sign in and they don’t have permissions. The “Federation mode” may be disabled and no users have been assigned to the directory. This means that the Okta directory has been setup to restrict users, but that specific user hasn’t been given access. If “Federation mode” is enabled then the user can sign in as long as they are assign to the Okta directory.