SSO Integration with Safeconsole 5.3+
SSO allows admins to easily log in to SafeConsole using 3rd party authentication. With Single Sign-On enabled, SafeConsole Admins can be synced from a centrally managed repository of users that allows for easier review and management.
SafeConsole has the potential to integrate with an SSO solution that utilizes a SAML 2.0 connector.
Solutions that have been tested and confirmed by the Datalocker Team: Please see the specific KB articles for SSO providers for more details.
PingOne
PingFederate: https://support.datalocker.com/support/solutions/articles/4000123302-pingfederate-integration-with-safeconsole
Okta: https://support.datalocker.com/support/solutions/articles/4000156041-okta-sso-configuration
SafeNet Trusted Access: https://support.datalocker.com/support/solutions/articles/4000189436-setting-up-sso-with-safenet-trusted-access
Important Information for Integration
Entity ID
The entity ID is also considered the Identifier of the SSO connector. This allows SafeConsole to determine which connector to use within your SSO solution.
Please note that the EntityID needs to match the Identity Provider (IdP) and SafeConsole.
SSO URLs
Login URL Example - https://SSOsolutionServer.com/adfs/ls/ (This will vary depending upon your SSO solution.)
OneLogin Example - https://mysafeconsoleserver.com/safeconsole/sso-login/acs
ACS (Consumer) URL Validator* example - ^https\:\/\/mysafeconsoleserver.com\/safeconsole\/sso-login\/acs$
Default Logout URL - https://mysafeconsoleserver.com/safeconsole/?logout (This URL will log you out of the SafeConsole server and not your entire SSO solution.)
Assertions
An assertion is an open standard for exchanging authentication and authorization data between the SafeConsole server and the SSO solution. The assertion would be implemented into the settings of the SSO connector. This allows the connector to know which solution to communicate with.
Example: https://mysafeconsoleserver.com/safeconsole/sso-login/acs
Required Attributes
memberOf - Sets the group memberships that are identified by SafeConsole. See Privileged Access Groups below to determine the level of group access.
Name ID - The LDAP attribute that is used to Authenticate into the SafeConsole Server.
Privileged Access Groups - By default, SafeConsole has three levels of user console access. The access level will need to be defined in the SSO connector during setup. The three default access levels are as follows: (On-Prem Only, recommend using custom
ADMINISTRATOR - Can Purchase Licenses, add administrators, configure devices, monitor audit logs, and perform device actions
MANAGER - Can configure devices, monitor audit logs, and perform device actions
SUPPORT - Can perform a limited number of device actions, such as password resets. Cannot change device configurations
Note: When using SSO please ensure that "Enable Custom Role-Based Security System" is checked in the "Admins" tab on your SafeConsole server. When adding users to roles be sure to match role names exactly as spelled as they are case-sensitive.
Certificates:
You will need two certificates to complete the integration between SafeConsole and your SSO solution: The Public Signing Certificate of your SafeConsole Server and the SSL certificate that is associated with your SSO Solution.
The SafeConsole certificate will be used as a signed certificate within the connector of the SSO solution. The SSO certificate will be used by SafeConsole to create a secure trust between both parties. You will need to be able to extract the x509 data of your SSO Certificate.
*The Public Signing Certificate is only required if the idP requires signature validation of the SAML Request. Not all idPs require this, example of some that do; ADFS, Oracle Access Manager, Ping Federation.*
To obtain the Public Signing Certificate of your SafeConsole server you will need to access the machine where SafeConsole is installed. (Note* If you are using SafeConsole Cloud please contact support for the certificate at [email protected])
1. Navigate to the "cert" folder in your installation location (Default: C:\Program Files\safeconsole\cert)
2. Copy the ca.p12 certificate (you will need the original password you set when you ran the SafeConsole Configurator for the first time)
3. Convert the certificate to X.509 (If your SSO provider accepts .p12 format then you can skip this step).
* The easiest way to get the certificate to X.509 is to install the .p12 file on the safeconsole server (Windows) by double-clicking it. Install the certificate to Trusted Root Certification Authorities store for the current user. You will need the original password set by the SafeConsole configurator on the first run. You can then export just the certificate (no Privatekey) using certmgr.msc and look for "SafeConsole CA" *
SSO Settings within the SafeConsole:
In your on prem SafeConsole, a user with the same email as your SSO solution must exist with the appropriate permissions.
To be able to be to continue with the steps below, you must be using an owner account, which is created by default. To get the password to this account, navigate to your SafeConsole folder and open sc_email_history in a text editor. Within that file, you should see a long URL which should let you choose your password for the owner admin account.
Login to your SafeConsole and navigate to Server Settings > Single Sign-On.
You may manually type in the required fields (Method 1), or upload the METADATA file obtained from your SSO solution which will automatically fill out the required fields (Method 2).
example from OneLogin to obtain METADATA file
Method 1:
Check the box to enable SSO
Select SAML2 from the drop-down
Enter the identifier of your SSO Connector
Input the SSO Endpoint URL
Input the SLO Endpoint URL
Input the X509 Data
Click Save.
Method 2:
Check the box to enable SSO
Select SAML2 from the drop-down
Upload the METADATA file that can be obtained from your SSO solution
Click Save
Please Note: If you are utilizing SafeConsole On-Premise, please make sure you have an Admin, Manager, and Support account/group assigned. This can be checked by running the "SafeConsole Configurator" from the SafeConsole host computer. The Single Sign-On subsystem requires that these roles are assigned to function properly.