Data tab configuration
Use this guide to configure the Data tab in the Web Admin for each SecureAuth IdP realm.
This includes directory integration and user profile field mapping.
Prerequisites
An on-premises directory must be established and ready to integrate with SecureAuth IdP
A Service Account must be created for SecureAuth IdP with read privileges to access the data store, and write privileges (optional) to update user information
Create a New Realm for the target resource for which the configuration settings will apply, or open an existing realm for which configurations have already been started
Configure the Overview tab in the Web Admin before configuring the Data tab
Data configuration steps
In the SecureAuth IdP Classic Experience, go to the Data tab.
In the Membership Connection Settings section, for the Datastore Type, select the directory with which SecureAuth IdP will integrate for Multi-Factor Authentication and assertion.
Follow the distinct configuration steps for the selected data store in addition to the configuration steps on this page.
You can find links for many of the data store configurations at the end of this topic.
Active Directory (sAMAccountName)
Active Directory (UPN)
Lightweight Directory Services (AD-LDS)
Lotus Domino
Novell eDirectory
Sun ONE
Tivoli Directory
Open LDAP
Other LDAP
SQL Server
Custom – for directories not listed. This would require custom coding – contact SecureAuth for configuration steps / requirements
ODBC
ASPNETDB
Web Service (Multi-Datastore)
Microsoft Azure AD
Oracle
WebAdmin (for SecureAuth0 Admin Realm only)
Warning
For Active Directory and other LDAP data stores, note the Search Attribute directory field value, e.g. sAMAccountName.
To use OATH OTPs for Multi-Factor Authentication, the Search Attribute directory field must be the same in the OATH Provisioning Realm and all realms using OATH OTPs for Multi-Factor Authentication.
In the Profile Provider Settings section, set which data store contains the profile fields used for authentication (telephone number, email address, knowledge-based questions).
Same As Above
To use the same data store selected in step 1, set this to True.
Use this setting if the selected data store contains the profile fields used for authentication.
Otherwise, to use a different data store, set this to False and select another data store in the next field.
Default Profile Provider
To use a different data store that contains the profile fields used for authentication, select another data store from the list.
If a different profile provider is selected (with Save As Above set to False in step 4), then in the Profile Connection Settings section, set the data store type from user profile information will be pulled. For example, Directory Server.
Note
No configuration is required in this section if Same as Above is set to True in step 4.
Follow the distinct configuration steps for the selected data store in addition to the configuration steps on this page.
You can find links for many of the data store configurations at the end of this topic.
Active Directory (sAMAccountName)
Active Directory (UPN)
Lightweight Directory Services (AD-LDS)
Lotus Domino
Novell eDirectory
Sun ONE
Tivoli Directory
Open LDAP
Other LDAP
SQL Server
Custom – for directories not listed. This would require custom coding – contact SecureAuth for configuration steps / requirements
ODBC
ASPNETDB
Web Service (Multi-Datastore)
Microsoft Azure AD
Oracle
WebAdmin (for SecureAuth0 Admin Realm only)
In the Profile Fields section, make the following configurations.
Property
Map this SecureAuth IdP property to the appropriate data store Field.
For example, for Groups, the field attribute in the data store would be memberOf.
Source
If you enable another directory in the Profile Connection Settings section, change this source from Default Provider.
Field
Map this field attribute to the SecureAuth IdP property.
For example, for Groups, the field attribute in the data store would be memberOf.
Data Format
The Data Format section indicates how the information is stored in the directory (not available for all Profile Properties):
Plain Text: Stored as regular text, readable (default)
Standard Encryption: Stored and encrypted using RSA encryption
Advanced Encryption: Stored and encrypted using AES encryption
Standard Hash: Stored and encrypted using SHA 256 hash
Plain Binary: Stored as a binary representation of the data (uses a .NET library to make it binary – may not be readable by all applications)
JSON: Stored in a universal format, readable by all applications (similar to Plain Text)
Encrypted JSON: Stored as JSON, with values inside encrypted using AES encryption
Warning
If using a SQL directory, then JSON or Encrypted JSON is not supported
For the Fingerprints, Push Notification Tokens, OATH Tokens, and Access Histories Properties, only Plain Binary can be utilized as the Data Format
Writable
If the SecureAuth IdP is to make changes to the property in the data store, select the Writable check box.
For example, a user might change their user account information, like a telephone number or it updates authentication mechanisms like knowedge-based questions or device fingerprints.
Note
The Fields shown in the screenshot are examples. Each data store is organized differently and might have different values for each Property.
If a required Property is not listed, click Add Property. Enter the name of the new property and click Add.
The new Property then appears at the bottom of the list and can then be mapped to the appropriate data store Field.
Optional. Use Global Aux Fields to add any additional identities or user information that is not stored in the on-premises data store, but will be used in assertion.
Save your changes.
