Add SQL Server data store
In the SecureAuth® Identity Platform, you can add a SQL Server data store to assert or manage user identity information.
Prerequisites
Identity Platform release 24.04 or later, cloud or hybrid deployment
For Identity Platform cloud deployments, have the SecureAuth Connector installed and connected
SQL Server data store. See SQL user data store tables and stored procedures configuration
Process
There are two parts to adding a data store in the Identity Platform — (1) adding the data store and (2) mapping the data store properties.
Step 1 of 2: Add a SQL Server data store
The first part of adding a SQL Server data store is configuring the data store name, connections, credentials, and search attributes.
On the left side of the Identity Platform page, click Data Stores.
Select the Data Stores tab.
Click Add a Data Store.
On the Add a Data Store page, start with the following configurations, depending on your deployment type.
Settings in hybrid deployments
Settings in cloud deployments
Data Store Name
Set the name of the data store.
Connection Type
Set to SQL Server.
Use this directory for user membership validation
Appears only in hybrid deployments
Use one of the following options:
On – Enable membership validation; use the directory to search for the user's membership in a user group.
This means the directory is a Membership Store, containing the password to validate with the username.
After the data store is saved, this field is the Membership Store label shown on the View Summary.
A common use case for a Membership Store would be to have a directory with username and password information (and maybe some profile information), and then have a second directory or database used to store and access data that the Identity Platform writes to the directory (such as device recognition, device enrollment, push notification tokens, and so on).
Off – Disable membership validation; use the directory to search only for the user profile information.
This means the directory is only used to find the username and profile information (such as phone number, email address, device recognition profiles, OATH tokens, and so on).
Group of connectors
Appears only in cloud deployments
Assign this data store to a SecureAuth Connector group.
To learn more about Connector groups, see Manage SecureAuth Connector groups.
In the Connection String section, set the connection string to the SQL Server.
Note
For information about content in the corporate connection string, see the external article All SQL Server SqlConnection Properties.
Connection String
The value in this field is the connection string auto-populated by the Data Source and Initial Catalog fields (unless a custom connection string is manually entered).
advanced mode
To manually enter the connection string, click the advanced mode link.
Data Source
Name or network address of the SQL Server instance to which to connect.
For example, 111.22.33.444\sqlserver
Initial Catalog
The initial catalog name (or database name).
For example, secureauthconsult
Enable Integrated Security
Move the slider to indicate whether to enable integrated security for a secure connection.
Persist Security Info
Move the slider to indicate whether to persist security information such as the password in the connection string.
In the Credentials section, provide the log in credentials to access the SQL data store.
Enter Service Account Credentials
With this option, enter the following fields:
User ID – SQL user ID email address for the service account login
Password – Password for the service account login
Test the data store connection by clicking Test Credentials.
Use CyberArk Vault for Credentials
With this option, enter at least one field for the service account login:
Username – User name of machine to be scanned by CyberArk Application Identity Manger (AIM). This information appears on the Account Details page of the CyberArk Password Vault Web Access (PVWA) Admin Console.
Address – Address of machine to be scanned by AIM.
Safe – Name of Access Control Safe where credentials are stored.
Folder – Name of folder where account resides (by default, it its the root folder).
Object – Unique identifier Object name for the account.
Test the data store connection by clicking Test Credentials.
In the Advanced Settings section, define how the service account password is to be stored in the directory.
Password Format
Choose one of the following formats:
Clear – Password is stored as plain text. This improves performance of storage and retrieval but is less secure.
Encrypted – Password is stored as encrypted and can be decrypted for password comparison or retrieval. This is more secure, but requires additional processing or storage.
Hashed – Password is hashed using a one-way hash algorithm and random salt-value. When password is validated, it is hashed with the salt value of the dates for verification. Hashed passwords cannot be retrieved.
Password Hashing
This option appears only when the Password Format is set to Hashed.
Set the password hashing encryption to use SHA-1 or SHA-256.
In the Stored Procedure Configuration section, use the default values unless custom stored procedures are used for membership and profile data access.
For more information, see SQL user data store tables and stored procedures configuration
Get User
Checks if a username exists, and returns the same username in the case that it does.
Create User
Inserts the username and password into the user table, and returns a MembershipCreateStatus enumeration.
Get/Validate Password
Gets the password, password salt, and password format.
Reset Password
Resets the password for the given user.
Get User Profile
Retrieves the profile of the given username (See Configuration Guide if using JSON).
Update User Profile
Updates user profile with the given profile information (See Configuration Guide if using JSON).
Click Continue.
The Map Data Store Properties page opens.
Step 2 of 2: Map the SQL Server data store properties
The second part of adding a SQL Server data store is mapping the data store properties.
Each user is uniquely identified by profile data that is read from or stored in your directories and databases.
The Identity Platform does not store user profiles, so your SQL Server attributes must be mapped to Identity Platform profile properties to be read and updated in the directory by the Identity Platform. The directory attribute mapped to the property is retrieved only when required for authentication or assertion purposes.
You cannot modify the Writable properties for the SQL Server data store from the Identity Store UI. Refer to your database provider for this configuration.
For more information about how data store profile properties are stored for on-premises, hybrid, or cloud Identity Platform deployments, see List of stored profile field properties.
Refer to the following table about attribute mapping and other information.
Column | Description |
|---|---|
Name and SQL Field | The profile property mappings are set by the SQL database configuration. |
Writable | You cannot modify the Writable properties for the SQL data store on the Identity Platform UI. Refer to your database provider for this configuration. |
Use Cloud Storage Available only in cloud deployments. | Store values in Aux IDs to the cloud profile database. When you select this check box, enter a description about the purpose of the Aux ID. To learn more, see How to set up Aux ID for cloud storage. |
Data Format | For cloud deployments, certain profile properties (for example, Push Notification Tokens, Behavioral Biometrics, and Device Profiles) are generated and used by SecureAuth, and stored in the SecureAuth cloud database. Selection options listed below may vary depending on your Identity Platform deployment:
|