Updated July 17, 2020
Once you have established communications with a SecureAuth Connector in the SecureAuth® Identity Platform, you can add data stores to assert or manage user identity information.
To migrate from SecureAuth IdP (on-prem) version 9.3 with an existing SQL Server data store configured using the New Experience UI to the Identity Platform (cloud), you will need to reenter the data store credentials after downloading and installing the SecureAuth Connector.
SQL Server data store
Make sure you have the correct SQL tables and stored procedures configured, specific to the Identity Platform version.
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.
The first part of adding a SQL Server data store is configuring the data store name, connections, credentials, and search attributes.
For the Use this database for user membership validation slider, use one of the following options:
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 database with username and password information (and maybe some profile information), and then have a second database used to store and access data that the Identity Platform writes to the database (such as device recognition, device enrollment, push notification tokens, and so on).
In the Connection String section, set the connection string to the SQL Server.
For information about content in the corporate connection string, see the external article All SQL Server SqlConnection Properties.
In the Credentials section, provide the log in credentials to access the SQL data store.
In the Advanced Settings section, define how the service account password is to be stored in the directory.
In the Stored Procedure Configuration section, use the default values unless custom stored procedures are used for membership and profile data access.
The Identity Platform is preconfigured to use the stored procedure values you have configured, specific to your version of the Identity Platform. See the appropriate topic:
For Identity Platform versions 19.07.01-11 (hotfix 11) and later, see SQL tables and stored procedures configuration (19.07.01-11+)
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.
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.
On the Map Data Store Properties page, for the mapped Aux ID 1 through Aux ID 10 fields, specify the Data Format to define how data is encrypted and stored in the directory.
For cloud deployments, any profile properties mapped to Aux ID 1 through Aux ID 10 are stored in the cloud. These properties are generated and used by SecureAuth, such as device recognition profiles, OATH tokens, push tokens, knowledge-based questions and answers (KBQ/KBA), PIN, and access histories.
The selection options are:
SQL tables and stored procedures configuration (9.1 to 19.07.10-10)
SQL tables and stored procedures configuration (19.07.01-11+)
View and edit data store integration