IBM Security Verify

Before you begin

You will need your socure_public_account_id, available in the RiskOS™ Dashboard on the Developer Workbench > API Keys page under the Customer ID section.

• Access Sandbox socure_public_account_id.

• Access Production socure_public_account_id.

Set Up Single Sign-On (SSO) with IBM Security Verify

1. Configure SAML in IBM Security Verify

Follow these steps to create a SAML 2.0 integration in IBM Security Verify:

1. Log into your IBM Security Verify account.
2. From the navigation sidebar, expand the Applications section and select Add an application.
3. On the Select Application Type form, select Custom Application.
4. On the General tab:
   • Settings: Check Enabled and Show on launchpad.
   • Descriptions: Enter a short description for this application.
   • Company name: Enter Socure.
   • Theme: Select default.
5. On the Sign-on tab:
   • Sign-on method: Select SAML 2.0.
   • Provider ID: Enter one of the following:
     • Sandbox environment: https://riskos.sandbox.socure.com/saml2/socure_public_account_id
     • Production environment: https://riskos.socure.com/saml2/socure_public_account_id
   • Assertion consumer service URL (HTTP - POST): Enter https://api-dashboardv2.socure.com/saml2/SSO.
   • Check Use identity provider initiated single sign-on.
   • Target URL: Leave blank.
   • Service provider SSO URL: Leave blank.
   • SessionNotOnOrAfter: Enter 7200.
6. Complete the Attribute mappings as follows:

• If you want to manage what role(s) a user should have when they access RiskOS, you will need to add a new custom attribute. Fill out the details of the new custom attribute as follows:
  • Data type: string array
  • Display Name: https://dashboard.socure.com/attributes/role
  • Variable Name: RoleName
  • Enum: Checked
  • Attribute Members:
  • Display name is flexible and can be defined as you prefer, however the value has to match a valid RiskOS™ system-defined role name.
• The following table lists the valid system-defined role names available in RiskOS™:

📘

Note:

In future releases, RiskOS™ will support custom role names.

2. Send the SAML metadata to Socure

After setting up the SAML App integration, click Download metadata to download the SAML metadata file and securely share it with Socure.

Do not copy and paste just the X.509 certificate from the SAML Setup Instructions page. Socure requires the full SAML metadata file (XML format), which includes your entity ID, endpoints, and certificates. Be sure to download and share the complete metadata file.

📘

Important: Customers must provide two separate metadata files to Socure:

• One for the RiskOS™ Sandbox environment
• One for the RiskOS™ Production environment

After receiving your SAML metadata file, your Technical Account Manager will confirm when SAML is enabled for your account.

3. Test the integration

To test the SAML integration, go to the IdP Admin Console, create a user, assign Socure's RiskOS™ app to the user and assign role(s) via the custom RoleName SAML attribute. When the user launches the RiskOS™ app from the IdP dashboard, the following occurs:

The Users tab on the Users and Roles page in RiskOS™ is populated with the user's name, email address, and phone number. The user is assigned the role(s) specified in the RoleName custom SAML attribute. If role(s) is not assigned, the system will default to assigning Analyst role to the user.

4. Assign users to RiskOS™

If you are planning to manage role assignment to users and you have configured the custom SAML attribute for RoleName, you can assign role(s) to the user when assigning the application. If a role is not assigned, the system will default to assigning Analyst role to the user.

📘

Note:

RiskOS™can have only 1 user assigned as Account Owner.

A role assigned to user is applicable in both Sandbox and Production. That is, if you assign a Developer role to a user, the user will have Developer role in both RiskOS Sandbox and RiskOS Production. In early 2026, we will be enhancing role-based access management to allow customers to assign roles by environment (e.g. assign [email protected] Administrator role only in Sandbox and assign only Developer role in Production).

📘

Note:

Users are required to re-authenticate every 12 hours by default; however, you can specify a shorter duration using the maxAuthenticationAge parameter for further security hardening.