Virtual Views of Cloud Directories and Services
Introduction
Cloud services like Salesforce, Google Directory, Azure AD (which stores identities that access services like Office 365), among others can be virtualized in RadiantOne and a default virtual view mounted at o=cloudservices,o=vds can be seen as an example. If you update the default data sources associated with this view, it should return your data. The following list includes the default data sources that you can edit to point to your service.
The default data sources mentioned below can be used as samples of virtualizing data sources reachable via an API. To configure new custom data sources, see the RadiantOne Context Builder Guide.
Cloud Directory or Service | RadiantOne Data Source |
---|---|
Salesforce | There are two methods supported for virtualizing Salesforce: JDBC or SCIM |
Azure AD | Edit graphapi Custom Data Source. |
Edit googledirectory Custom Data Source. | |
Concur | Edit concur Custom Data Source. Script to call the Concur API located <RLI_HOME>\vds_server\custom\src\com\rli\scripts\customobjects. Updates to the API calls might be necessary. |
Workday | Edit workdayhr Custom Data Source. Script to call the Workday API located <RLI_HOME>\vds_server\custom\src\com\rli\scripts\customobjects. Updates to the API calls might be necessary. |
Any service accessible via SCIM v1 | Edit scimclient Custom Data Source. |
Any service accessible via SCIM v2 | Edit scimclient2 Custom Data Source. |
SharePoint Online in Office 365 | Edit sharepointonline Custom Data Source to virtualize identities in the User Profile Database. |
Edit oktaclient Custom Data Source. | |
Edit scimclient2 Custom Data Source (or clone it to create one specific for SailPoint). |
To connect to a new cloud service and create a virtual view, see the RadiantOne Context Builder Guide section on Custom Data Sources.
More details about virtualizing Salesforce, Azure AD, Google Directory, Okta Universal Directory, SailPoint IdentityIQ and PingOne Directory by leveraging the sample default custom data sources can be found in this chapter.
Operations Supported
The default custom data sources support Read, Update, and Delete (or deactivate) operations but most do not support authentication (support a delegated authentication request from FID). Therefore, virtual views of these sources are primarily used for joining with other virtual views to extend user profiles and/or attributes for enforcing authorization and auditing. For example, you can have a virtual view of an LDAP directory (that would handle authentication requests) that is joined with a virtual view of Salesforce (to retrieve additional profile attributes to augment the user entries from the LDAP directory). The only custom data sources that currently support authentication (RadiantOne translating the BIND request into a credentials checking request) are Okta Universal Directory, PingOne Directory, and Azure AD (when MFA is not enabled).
Change Detection (Connectors) for Cache Refresh
If you configure persistent cache for virtual views of cloud directories/services, the change detection mechanisms for cache refresh are limited to Periodic and Custom (only for sources that contain a timestamp attribute for their entries, or Differential Query like Azure AD). The periodic change detection mechanism requires the entire data set to be retrieved at each polling interval and then the connector determines what has changed. The Custom change detection mechanism is a special timestamp-based approach that works with Azure AD (which also leverages Differential Query), Okta, and any SCIM-accessible backend. If the cloud directory/service does not support SCIM (and is something other than Azure AD or Okta), then the periodic option is the only choice for detecting changes for persistent cache refreshes.
For details on persistent cache refresh connectors, see the RadiantOne Deployment and Tuning Guide.
Calling the Web Service through a Proxy Server
If your company requires API calls to be made through a Web Proxy Server, add a property named “proxy” with a value that points to the proxy server and port (e.g. rli.vip.proxy.com:9090) to the custom data source. If SSL is required, add a property named “proxyssl” with a value of true.
Salesforce
RadiantOne can virtualize Salesforce via SCIM or JDBC. Both configurations are described in this section.
SCIM Access
In order for RadiantOne to virtualize Salesforce via SCIM, it must authenticate using OAuth. RadiantOne leverages the Username-Password OAuth authentication flow (Resource Owner Password Credentials Grant) for SCIM access as this flow operates non-interactively, without requiring a user to actively give authorization. This requires you to create a connected app in Salesforce to associate with RadiantOne. You should consult your Salesforce documentation for steps on how to create a Connected Application that has been enabled for OAuth. The steps below provide general guidance and may not reflect the latest steps in Salesforce.
Create a Salesforce Connected Application
-
Log into Salesforce and go to Setup > Apps > App Manager and click New Connected App.
Figure 1: Creating a Salesforce Connected App
-
Enter a name for the application, email to associate with the application and check the option to Enable OAuth Settings.
-
Enter a CallBack URL. RadiantOne doesn’t use this so the value doesn’t really matter. You can use: https://www.radiantlogic.com
-
Select the OAuth scopes that are applicable and click to add them.
-
Leave all other defaults and click Save.
Figure 2: Configuring Salesforce Connected App
WarningAllow up to 10 minutes before using the connected app.
-
After clicking save, you are warned about the 10-minute wait time. Click Continue.
-
Take note of the Consumer Key shown on the summary page. You need this value to configure RadiantOne.
-
On the summary page, next to “Consumer Secret”, click “Click to Reveal” and take note of the value. You need this value to configure RadiantOne.
Figure 3: Sample Salesforce Connected App
If you did not note the consumer key and secret values, you can return to this information from the App Manager section by selecting “View” from the drop-down list next to your app.
Figure 4: Viewing Consumer Key and Secret for Connected App
Configure a RadiantOne SCIM Data Source
-
In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom data Sources section, select scimclient and click Edit.
NoteIf you are already using the scimclient custom data source to virtualize a SCIM backend, click the Clone button to make a copy that you can work with for Salesforce to avoid impacting your existing configuration.
-
Click Add.
-
Enter oauthurl for the Name property and provide a value of https://login.salesforce.com/services/oauth2/token which is the Salesforce Token Endpoint.
-
Click OK.
-
Click Add.
-
Enter oauthclientid for the Name property and provide the Consumer Key value associated with your Salesforce Application.
Figure 8.5: Sample Consumer Key Value
-
Click OK.
-
Click Add.
-
Enter oauthclientsecret for the Name property and provide the Consumer Secret value associated with your Salesforce Application.
-
Click OK.
-
Select the url property and click Edit.
-
Enter the value matching your Salesforce SCIM service. The syntax is:
https://
<your_SCIMservice_url>
/services/scim/v1Figure 8.6: The value matching your Salesforce SCIM service
This URL should contain the same address you see when you are logged into Salesforce.
Figure 8.7: Salesforce SCIM URL
-
Click OK.
-
Select the username property and click Edit.
-
Enter your Salesforce username (email).
-
Click OK.
-
Select the password property and click Edit.
-
Enter the password (which is your password appended with the security token you received from Salesforce) associated with your Salesforce user name.
-
Click OK.
-
Click Save.
Configure a RadiantOne Virtual View
RadiantOne includes a default SCIM schema file that can be modified to meet the needs of Salesforce. This section describes how to modify the default SCIM schema template and create a basic virtual view from Salesforce.
-
Go to the Main Control Panel > Context Builder.
-
Choose File > Open > Schema.
-
Select the scimclient.orx and click OK.
-
The SCIM schema information is going to be modified slightly for Salesforce, so save the file with a new name to avoid working with the default template. Click and enter the new name (e.g. salesforcescimclient) and click OK.
NoteThe default data source associated with scimclient.orx is scimclient. if you cloned the default scimclient custom data source to work with Salesforce, right-click on the file name and choose Edit Connection String.
Figure 8.8: The Edit Connection String Option
Click “Edit” to select the appropriate custom data source.
Figure 9: Click Edit to select the appropriate custom data source
-
Expand the file name > Objects > Tables and right-click on Users.
-
Choose Edit Primary Key(s).
Figure 10: Editing Primary Key for SCIM Schema
-
Select the id attribute from the attributes list and use to move it to the column on the right.
-
Select the username attribute from the column on the right and use to move it to the attributes column on the left.
Figure 11: Setting Primary Key
-
Click Apply.
-
Click .
WarningTo virtualize group objects, define the primary key as ‘id’ just like you did above for the users object. Only Users and Group objects are in the schema definition by default. To virtualize other objects via SCIM, you must first create the object (Right-click on Tables > Add New Object) and add the attribute 'id' and define it as the primary key, just like you did above for the users object.
-
Click the View Designer tab.
-
Click .
-
Enter a name for the virtual view.
-
Click “Select” and browse to the salesforcescimclient file on the Custom Schemas tab and click OK.
NoteThe virtual view definition can be customized as needed. The steps in this guide create a basic virtual view of users.
Figure 12: Creating a Virtual View from Salesforce
-
Select the salesforcescimclient node on the left and choose New Label on the right.
-
Enter “object” for the Level type and “user” for the value.
-
Click OK.
-
Click object=user in the tree on the left and choose New Content on the right.
-
Select the Users object and click OK.
Figure 8.13: Salesforce Virtual View
-
For the selected users content node, click the Attributes tab.
-
Click to expose all available attributes in the virtual view.
-
Click . Keep the same name (e.g. salesforcescimclient).
-
To mount this virtual view in the RadiantOne namespace, do so from the Main Control Panel > Directory Namespace tab.
-
To test the virtual view, go to the Main Control Panel > Directory Browser tab and navigate below the naming context where you mounted the view in step 23. Your Salesforce user accounts are shown.
Figure 14: Sample Run Time Virtual View from Salesforce
JDBC Access
As an alternative to using SCIM, RadiantOne includes a JDBC driver to virtualize Salesforce. This section describes the configuration.
-
On the Main Control Panel > Settings tab > Server Backend section, go to DB Data Sources.
-
On the right, click on radiantsalesforce and click Edit.
Figure 8.15: Salesforce Custom Data Source
-
Enter your Salesforce user email in the User property.
-
Enter your Salesforce user’s password (which is your password appended with the security token you received from Salesforce) in the Password property.
-
If you are connecting to a production instance of Salesforce, the URL value should be: jdbc:salesforce:
If you are connecting to a sandbox instance of Salesforce, the following URL can be used: jdbc:salesforce:test
If you are connecting to a custom salesforce domain, use jdbc:salesforce:<domain>
, such as "jdbc:salesforce:mycompany"
- Click Save. At this point, the default Salesforce view located at dv=salesforce,o=cloudservices,o=vds should return your data (contacts and accounts are the objects defined in the view).
- To view the schema associated with the radiantsalesforce data source, go to the Context Builder tab, Schema Manager sub-tab and open the schema named salesforce. The objects that can be virtualized from Salesforce are described in this file.
- To create a new virtual view, use the Context Builder tab > View Designer sub-tab. For details on using View Designer, see the RadiantOne Context Builder Guide.
Getting a Security Token from Salesforce
You should consult your Salesforce documentation for steps on how to acquire a security token for accessing Salesforce. The steps below provide general guidance and may not reflect the latest steps in Salesforce.
-
Log in to Salesforce with the account you will use to connect to Salesforce from RadiantOne.
-
In the top right header of the main page, locate the link with your name.
-
Click the down arrow and select My Settings.
-
On the My Settings Page expand Personal.
-
Select the Reset My Security Token option. Clicking the Reset Security Token button sends an email (to the email address associated with your Salesforce account) containing a new security token. Record this token string as you need to use this as part of the password when configuring the RadiantOne database data source that points to your Salesforce instance.
Azure Active Directory
Create Azure AD Application
If you have not already created an application in Azure AD, you must do so prior to configuring RadiantOne.
Note - The steps below provide general guidance and may not reflect the latest Microsoft Azure AD interface. For more detailed configuration steps, refer to the Microsoft Azure Active Directory documentation.
-
In the Microsoft Azure portal associated with your Azure AD, click on Manage -> App Registrations and then the New Registration button.
-
Provide a name for the application.
-
Select the option for “Accounts in this organizational directory only” for the Supported Account Types.
-
You do not need to provide a Redirect URI.
-
Click Register. The registered app is displayed. Take note of the Application ID.
Figure 8.16: Azure AD Application
-
Click the application to access the specific settings.
-
Navigate to Certificates & Secrets.
-
In the Client Secret Section, click New Client Secret.
NoteIf you configured a certificate to use instead of a client secret, you will reference the certificate in the RadiantOne configuration instead and can skip this step and steps 9-10 below.
-
Enter a description, expiration and click Add .
-
Take note of the secret key value displayed.
-
Navigate to API Permissions and click Add a Permission.
-
RadiantOne supports both the legacy Azure Active Directory Graph API and the Microsoft Graph API. If you use the default graphapi custom data source in RadiantOne, it uses the legacy Azure Active Directory Graph API. If you use the default mgraph custom data source in RadiantOne, it uses the Microsoft Graph API. On the Microsoft API tab, be sure to select permission for the applicable API, based on what custom data source you are going to use.
NoteAzure Active Directory Graph is in the legacy API section. Since support for the Azure Active Directory Graph API will soon be deprecated, it is recommended you use the RadiantOne mgraph custom data source and the Microsoft Graph API.
-
Select Application permissions for the Type.
-
Enable Directory.Read.All for read-only access. If you want read/write access to the data, enable the Directory.ReadWrite.All access.
NoteIf you need to be able to delete groups, you must also have the Group.ReadWrite.All permission.
Figure 8.17: Azure AD Application Permissions
-
Click Add Permissions.
-
In the Configured Permissions section, click Grant Admin Consent.
-
Click Yes.
It might take a few minutes for the permissions to take effect. If you change the permissions after you have started testing with RadiantOne, you should restart the RadiantOne service to force the new permissions to take effect.
Remember, if you are going to use the graphapi custom data source (as outlined in the next section) then the API permissions (for read/write access) should be assigned to the Azure Active Directory Graph API.
Figure 18: Read and write permissions for the Azure Active Directory Graph API
If you are going to use the mgraph custom data source (as outlined in the next section) then the API permissions (for read/write access) should be assigned to the Microsoft Graph API.
Figure 19: Read and write permissions for the Microsoft Graph API.
To support delegating authentication requests to Azure AD (RadiantOne getting an LDAP bind request and sending the credentials checking to Azure AD), when using the mgraph custom data source, set “Treat Application as a public client” to Yes in the Authentication configuration for the application.
Figure 20: The "Treat Application as a public client" option
To support deleting user entries in Azure AD, one additional application API permission is required: User.ReadWrite.All. To support deleting groups, you must also have the Group.ReadWrite.all permission.
Figure 21: The User.Read.Write.All permission
Configure RadiantOne Custom Data Source
The Azure application APPLICATION ID and SECRET KEY (or Certificate) described in the previous section are required to configure the Azure AD data source in RadiantOne.
RadiantOne supports both the legacy Azure Active Directory Graph API and the Microsoft Graph API. If you use the default graphapi custom data source in RadiantOne, it uses the legacy Azure Active Directory Graph API. If you use the default mgraph custom data source in RadiantOne, it uses the Microsoft Graph API.
Since the Azure Active Directory Graph API will soon be deprecated by Microsoft, it is advised to use the mgraph custom data source.
-
On the Main Control Panel > Settings tab > Server Backend section, go to Custom Data Sources.
-
On the right, click either the graphapi or mgraph data source and click Edit.
Figure 8.22: Azure AD Custom Data Source
-
Select the username property and click Edit.
-
Enter the value of the Azure AD Application ID.
-
(Optional) If you are connecting to Azure AD with a certificate instead of a client secret, complete steps 5-14. Otherwise, skip to step 15. Click Add and create a property named “clientid”.
-
Enter the Azure AD Application ID for the clientid property value and click OK.
-
Click Add and create a property named auth_cert_password.
-
Enter the value of your certificate password for the auth_cert_password property and click OK.
-
Click Add and create a property named auth_cert_path.
-
Enter the value of your certificate path for the auth_cert_path property and click OK.
-
Click Add and create a property named auth_tenant.
-
Enter the value of your azure AD tenant for the auth_tenant property and click OK.
-
Click Add and create a property named auth_type.
-
Enter the value access_token_with_certificate and click OK.
-
(Optional) If you are using a client secret instead of a certificate, select the password property and click Edit.
-
(Optional) If you are using a client secret instead of a certificate, enter the secret key associated with your Azure AD application.
-
Select the URL property and click Edit. Enter the URL for your Azure AD tenant (if using graphapi, this would look like:
https://graph.windows.net/<your _tenant_name>
. If using mgraph, this would look like: https://graph.microsoft.com/beta). -
Click OK.
-
Select the oauthURL property and click Edit.
-
Enter the URL for your Azure AD tenant token endpoint (if using graphapi, this would look like:
https://login.microsoftonline.com/<your _tenant_name>/oauth2/token
. If using mgraph, this would look like:https://login.microsoftonline.com/<your _tenant_name>/oauth2/v2.0/token
). -
Click OK.
-
Select the active property and click Edit.
-
Enter true to activate the data source.
-
Click OK.
-
If your company requires API calls to be made through a Web Proxy Server, add a property named “proxy” with a value that points to the proxy server and port (e.g. rli.vip.proxy.com:9090). If SSL is required, add a property named “proxyssl” with a value of true.
If SSL is used, ensure RadiantOne trusts the public certificate for the proxy server. To manually trust the certificate, import it the RadiantOne Client Certificate Truststore from the Main Control Panel > Settings > Security > Client Certificate Truststore.
-
Click OK.
-
(If using the mgraph custom data source) Select the scope property and click Edit. If the scope doesn’t exist, click Add to create it.
-
The scope property value should be: https://graph.microsoft.us/.default for U.S. Government tenants (and https://graph.microsoft.com/.default for non-government tenants).
-
Click OK.
-
(If using the mgraph custom data source and Azure AD contains large volumes of users and/or groups; ~50K+ users) add two new properties: max_retries_on_error and retry_interval_on_error. These properties dictate the behavior of error recovery when initializing persistent cache on the virtual view of the Azure AD backend. Max_retries_on_error defines the number of retries when an error is encountered. This must be a positive, numeric value. After the maximum retries is exhausted, the exception is logged and the persistent cache initialization is stopped. If this property is not present, or contains an invalid value, no retry logic is used. Retry_interval_on_error indicates the amount of time to wait before the next retry. This value is in milliseconds. If this property is not present, or contains an invalid value, a default value of 10000 ms (10 seconds) is used.
After you successfully initialize the persistent cache, edit the mgraph custom data source and delete the max_retries_on_error and retry_interval_on_error properties so they don’t interfere with the persistent cache connector refresh logic which enforces similar properties.
-
If you are going to virtualize Azure AD Groups, see Working with Azure AD Groups and you might need to add more properties to the graphapi data source described in these steps.
-
Click Save. At this point, if you are using the graphapi custom data source, the default Azure view located at dv=graphapi,o=cloudservices,o=vds should return your data. If you are using the mgraph custom data source, you must create a new Root Naming Context on the Directory Namespace tab and mount the mgraph.dvx (default virtual view) in order to see the data.
If you are using Azure Active Directory B2C, you can use the graphapib2c custom data source instead.
Figure 23: Azure AD B2C Custom Data Source
Working with Azure AD Groups
When working with Azure AD groups, the entries can be returned either with or without the members. Both options are described in the following sections.
This section is only applicable when using the graphapi custom data source. If you are using the mgraph custom data source, the group members are always returned with their virtual DNs (as long as users are in the same view definition as groups), comprised of either the user’s ID (GUID) or userPrincipalName depending on which attribute is defined as the “primary key” of the “Users” object in the mgraph.orx/mgraph.dvx files. Keep in mind that the member value must match the definition of the user in the view. For example, a group member identified by user=[email protected],Category=User,dv=mgraph should match a user entry at this location/DN. If the group member is identified by the ID (e.g. users=859bab3d-1a09-4a7c-acc0-b1f2bef16f05,object=users,dv=graphapi,o=cloudservices,o=vds), then the user location/container in the view defintion should be based on the ID of the user as well.
Returning Group Members
If you are virtualizing Azure AD groups using the default graphapi custom data source, the default behavior of RadiantOne is to get the group members returned as DNs comprised of the user's userPrincipalName. This can be very time-consuming due to the extra processing required by RadiantOne to look-up and compute the userPrincipalName for each member. Therefore, this approach is only feasible if you have fewer than 500 relatively small groups (having fewer than a few hundred members). An example is shown below.
Figure 8.24: Group Members Returned with UserPrincipalName in the DN
If you have more than 500 groups and/or large groups (many members) you can optimize the return of members by adding memberoid=true in the graphapi custom data source. With the addition of this setting, the group members are returned as DNs comprised of the user's ObjectID instead of the userPrincipalName. This approach is more efficient since there is no extra translation of the member DNs. An example is shown below.
Figure 25: Group Members Returned with ObjectID in the DN
To add the memberoid property:
-
Navigate to the Main Control Panel > Settings > Server Backend > Custom Data Sources.
-
Select graphapi and click Edit.
-
Click Add.
-
Enter memberoid as the property name.
-
Enter true for the value.
-
Click OK.
Figure 26: Adding Memberoid Property
-
Click Save.
-
Since the group members are returned with their ObjectID (comprising the DN), you must make sure the corresponding virtual view of Azure AD users is also based on ObjectID. The default graphapi.orx schema and graphapi.dvx virtual view are based on userPrincipalName not ObjectID. To change the default schema, open graphapi.orx in Main Control Panel > Context Builder tab > Schema Manager sub-tab (it is listed on the Custom Schemas tab).
-
Right-click on the Users object and choose Edit Primary Key.
-
Define the Objectid attribute as the primary key and remove userPrincipalName.
Figure 8.27: Modifying Primary Key for Users Object
-
Click Apply.
-
Save the schema.
-
Open graphapi.dvx in Main Control Panel > Context Builder tab > View Designer sub-tab.
-
In the tree view on the left, below graphapi, expand Object=Users and select the users content node.
-
Click Delete to remove this old definition.
-
In the tree view on the left, below graphapi, click Object=Users and choose New Content on the right.
-
Select Users and click OK.
-
On the Attributes tab for this node, use to define specific attributes as part of the view, or click to define all attributes.
WarningIf you do not require directReports, ownedDevices, registeredDevices or other backlink attributes to be returned, avoid defining them in the virtual view. This will avoid costly lookups to return these attributes and greatly improve performance. If you need to support searches on surname, be sure to add “sn” as the Virtual Name as outlined in Virtualizing Surname/SN Attribute.
-
Click to save the virtual view.
-
From the Main Control Panel > Directory Browser, expand the virtual view (e.g. o=vds > o=cloudservices > dv=graphapi > object=users) and ensure the user DN is returned with the Object ID. This matches how they are returned in the group membership.
Figure 8.28: Users Returned with ObjectID in the DN
Returning Groups without Members for Searches with One Level or Sub Tree Scope
If you only need the basic group information without the members, on queries containing one level or sub tree scope, you can configure ignoremember=true in the graphapi custom data source. This is the most efficient method to get groups from Azure AD since no extra request for members is required. With this property, RadiantOne does not return members in the group entries for queries containing one level or sub tree scope. The members are only returned for group queries using base scope. On base searches, the members are returned with their UserPrincipalName in the DN.
If you set memberoid=true as described in the previous section, that value overrides the ignoremember=true setting. It is not recommended to use both ignoremember=true and memberoid=true.
If you do not want group members returned at all, no matter the search scope, edit the graphapi.dvx file in the Main Control Panel > Context Builder tab > View Designer sub-tab and remove the member attribute on the Attributes tab, for the objectid content node below object=groups.**
To add the ignoremember property:
-
Navigate to the Main Control Panel > Settings > Server Backend > Custom Data Sources.
-
Select graphapi and click Edit.
-
Click Add.
-
Enter ignoremember as the property name.
-
Enter true for the value.
-
Click OK.
Figure 8.29: Adding Ignoremember Property
-
Click Save.
In the example shown below, group entries are returned without members. Note that a basic LDAP command line query is used. Using the Main Control Panel -> Directory Browser tab can be confusing because the “click” on the group entry (when browsing) is actually doing a base search, in which case the members are always returned.
C:\SunResourceKit>ldapsearch -h doc-e1win1 -p 2389 -D "cn=directory manager" -w secretsecret -b "object=groups,dv=graphapi,o=cloudservices,o=vds" -s one (displayName=Sales)
version: 1
dn: objectid=68feb57e-7775-455b-be7e-4844aee817d6,object=groups,dv=graphapi,o=cloudservices,o=vds
mailnickname: d964c0c4-9eb8-4c4f-aaae-43ca687be1dc
owners: users=b7c684a9-c5c0-4dee-aead-21eae98dd86a,object=users,dv=graphapi,o=cloudservices,o=vds
displayname: Sales
odatatype: Microsoft.DirectoryServices.Group
objectclass: top
objectclass: vdgroups
objectid: 68feb57e-7775-455b-be7e-4844aee817d6
securityenabled: true
objecttype: Group
description: The group has access to Salesforce
mailenabled: false
Working with Multiple Azure AD Tenants
To work with multiple Azure AD tenants, you can clone the default graphapi or mgraph custom data source and change the properties to point to the tenant.
-
From the Main Control Panel > Settings tab > Server Backend > Custom Data Sources, select graphapi and click Clone.
-
Enter a data source name (e.g. graphapitenantb) and click Clone.
-
Click OK to exit the confirmation.
-
Select the new custom data source (e.g. graphapitenantb) and click Edit.
-
Enter the properties needed to connect to the applicable tenant. The properties were described in the previous section.
Azure AD Schema
A schema file contains the metadata leveraged by RadiantOne to create virtual views of a data source. The default graphapi custom data source is associated with a schema file named graphapi.orx. The default mgraph custom data source is associated with a schema file named mgraph.orx. These files can be opened and modified in the Schema Manager sub-tab on the Main Control Panel > Context Builder tab. For details on this tool, see the RadiantOne Context Builder Guide.
The default objects defined in the schema are Contacts, Devices, Groups and Users.
Any attributes that you want clients to use in a search filter, or insert/update, must be manually added to the applicable object definition in the schema file (right-click on the Fields level below the object and choose Add New Attribute). Once they are added to the schema file, make sure the attribute(s) is also properly added to the virtual view.
Figure 30: Graphapi Schema File
If you are using Azure AD B2C, use the graphapib2c.orx file instead of the graphapi.orx file.
Working with Extension Attributes
To work with extension attributes in Azure objects, add the attribute name to the applicable object in the schema file (graphapi.orx or mgraph.orx based on the Azure AD API you are using). For example, if the extension attribute in Azure AD was: extension_0fe2bf0f259e4b2b8eee56ec9365117c_skypeId add an attribute named “extension_0fe2bf0f259e4b2b8eee56ec9365117c_skypeId” that has a virtual name/alias of “skypeId” to the object. Notice that the extension attribute name is comprised of your application ID. If you don’t know the application ID, you can go to https://graphexplorer.azurewebsites.net. Click the login link at the top-right corner, and sign in using the credentials for an administrator account in your organization’s directory. After you have signed in, click the URL in the resource text box (next to the GET button) and select the URL that ends in applications/ then click GET or click the enter key. Find the desired application entry from the results, and then copy its appId value, such as the following: "appId": "41ebd369-484d-4088-bab5-c9077f9e13a7"
Figure 31: Copying the appId value
Once you have the appId, follow the steps below.
-
On the Main Control Panel > Context Builder > Schema Manager sub-tab, right-click on the Fields level below the object and choose Add New Attribute.
-
Enter the extension attribute full name using the appId value with the hyphens removed (e.g. extension_41ebd369484d4088bab5c9077f9e13a7_skypeId) with an alias for the friendly attribute name (e.g. skypeId).
Figure 8.32: Example Extension Attribute
-
Click Add.
-
Click Save.
The case used in Azure AD to create the extension attribute must match the case used when adding the extension attribute to the schema. In the example above, the “I” in skypeId is in uppercase. Therefore, when adding the extension attribute to the graphapi schema, make sure to follow this case-sensitive syntax.
Azure AD Virtual View
The default graphapi custom data source is associated with a virtual view file named graphapi.dvx. The default mgraph custom data source is associated with a virtual view file named mgraph.dvx. These files can be opened and modified in the Main Control Panel > Context Builder tab > View Designer sub-tab.
If you are using Azure AD B2C, use the graphapib2c.dvx file instead of the graphapi.dvx or mgraph.dvx files.
Figure 8.33: Mgraph Virtual View
If you’ve modified the graphapi.orx or mgraph.orx schema files to support extension attributes or if you want to limit the Azure AD attributes returned in the virtual view, you can modify the graphapi.dvx/mgraph.dvx files accordingly.
-
On Main Control Panel > Context Builder tab > View Designer sub-tab, choose File > Open > View.
-
Select graphapi.dvx or mgraph.dvx and click OK.
-
In the Tree View, expand below the object you’ve added extension attributes for.
-
Select the content node associated with the object.
-
On the Attributes tab, select the extension attribute from the source attribute list (on the left) and use the button and move it to the published attribute list (on the right).
If you do not require directReports, ownedDevices, registeredDevices or other backlink attributes to be returned, avoid defining them in the virtual view. This will avoid costly lookups to return these attributes and greatly improve performance.
- Save the virtual view. The run time view mounted at dv=graphapi,o=cloudservices,o=vds should now return the extension attributes. If you are using the mgraph.dvx file, you can create a New Root Naming Context in the Main Control Panel > Directory Namespace tab and mount the mgraph.dvx file there.
To create a new virtual view, load the graphapi.orx or mgraph.orx schema file in View Designer and define the new view. For details on using View Designer, see the RadiantOne Context Builder Guide.
Returning MemberOf for Users
Users have a memberOf attribute which is the back link to the group entry to which they are related. The value of the memberOf attribute is comprised of the Group entry's GUID. The default mgraph.dvx virtual view also returns a friendly memberOfDisplayName attribute that contains the display name attribute of the group entry. Clients can use this value for a more friendly display of the groups the user is associated with.
Virtualizing Surname/SN Attribute
The Azure AD schema uses the attribute “surname” to store a user’s last name. The RadiantOne default LDAP schema includes the following attribute type definition for “sn”:
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surName' ) DESC 'Standard LDAP attribute type' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' )
This schema definition can cause problems if clients issue searches or updates for the Azure AD view using a filter of (surname=<last_name>) because RadiantOne automatically translates this into a filter of (sn=<last_name>) when it queries Azure AD. Since the attribute in Azure AD is “surname” and not “sn”, the expected entry is not returned. To avoid this, you can either configure a mapping in the virtual view to map surname to sn, or edit the RadiantOne FID schema and remove the surname mapping from the sn attribute.
An alias of “streetaddress” is defined for the street attribute, and can run into the same issues. Either remove the alias from the RadiantOne FID schema, or remap properly in the virtual view using the same process outlined for the surname attribute below.
To configure a mapping for the surname attribute:
-
On the Main Control Panel > Context Builder tab > View Designer sub-tab, click .
-
Select graphapi.dvx or mgraph.dvx and click OK.
-
Select the “users” content node (below object=users if using the graphapi.dvx file, or the “user” content node below Category=Users if using mgraph.dvx file) in the Tree View.
-
Choose the Attributes tab.
-
Enter sn in the Virtual Name column for the surname attribute.
-
Save the virtual view.
Figure 8.34: Mgraph Virtual View with Mapping for Surname Attribute
This configuration supports clients that request filters with (sn=<last_name>) or (surname=<last_name>).
If you only want to support client requests with filters using (surname=<last_name>), you can edit the RadiantOne LDAP schema to remove the surname alias from the sn attribute.
-
Navigate to <RLI_HOME>\vds_server\conf and edit ldapsechema_00.ldif.
-
Remove the 'surName' and the ( ) from the following definition: attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surName' ) DESC 'Standard LDAP attribute type' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ).
-
Save the file.
Google Directory
The steps below provide general guidance and may not reflect the latest Google Directory interface. For more detailed configuration steps, refer to the Google Directory documentation.
To virtualize Google Directory, a Service Account on the domain must be set to enable the connection.
-
Go to the developer console and log in as an administrator.
Developer console -https://console.developers.google.com/project
Admin console -https://admin.google.com
orhttps://admin.google.com/<your-domain>/AdminHome
-
Create a new project.
-
Click the new project and accept the default id if requested.
-
On the left tab, go to “APIs & auth” > APIs and enable the “Admin SDK” API and make sure it displays in the list of enabled APIs and the status is ON.
-
Go to “APIs & auth” > credentials.
-
In OAuth, create a new client ID and select the type “Service Account” and validate it by clicking “Create Client ID”.
Figure 8.35: Google Service Account
-
Verify that the service account appears in API Project > Permissions.
WarningTake note of the client ID (<numbers-numbers&letters>.apps.googleusercontent.com) and the email address (
<same>@developer.gserviceaccount.com
) attached to the service account created, as you will need them later. Also notice that your browser just downloaded the P12 certificate that is needed to authenticate the Service account. -
Go to the Admin console and log in as an administrator for your domain.
-
Go to Security (if it does not appear on the dashboard/homepage, click “More controls” at the bottom).
-
In Security, click API reference and check “Enable API access”.
Figure 8.36: Enabling Google API Access
-
In Security, click “show more” then “Advanced settings” then “Manage API client access”. Here you can authorize the service account with different scopes that constrain its access to data.
-
In client name, fill in the client ID of the service account, and in the API scopes textbox fill in the following scopes as is:
-
Click “Authorize”. The service account is now entitled to view and manage all Directory data.
Figure 37: Enabling Google API Access
Define Google Directory Data Source
RadiantOne includes a custom data source defined for Google Directory. This default data source can be updated with connection criteria to your Google Directory instance. These steps are described in this section.
You need the following information to update the data source. This information was described in the previous section.
domain: your domain name (e.g. radiantlogic.com).
service_account_user: the email of the admin account you created the service account with.
service_account_email: the email of the service account.
service_account_p12_certificate: the full path on the server to the p12 certificate file.
-
On the Main Control Panel > Settings tab > Server Backend section, go to Custom Data Sources.
-
On the right, click on googledirectory and click Edit.
Figure 8.38: Google Directory Custom Data Source
-
Select the domain property and click Edit.
-
Enter your domain name in the Domain parameter.
-
Select the service_account_p12_certificate property and click Edit.
-
Enter the full path to your certificate, including your certificate name and click OK.
-
In the Custom Properties, select the service_account_user property and click Edit.
-
Enter the value of the user account associated with the super admin role in your Google Directory and click OK.
-
In the Custom Properties, select the service_account_email property and click Edit.
-
Enter the value of the email account associated with your service account in the Google Directory and click OK.
-
Click Save.
-
A default virtual view named googledirectory.dvx is included with RadiantOne. This virtual view is associated with the googledirectory data source. Mount this virtual view in your RadiantOne namespace to view the data from your Google Directory. To mount the view, go to the Main Control Panel -> Directory Namespace tab.
-
Although the googledirectory virtual view can be mounted at any available label in the namespace, this guide describes how to mount the view below a new root naming context. On the Directory Namespace tab, click New Naming Context.
-
Enter a new root naming context (e.g. o=googledirectory) and select the Virtual Tree option.
Figure 8.39: New Root Naming Context
-
Click Next.
-
Choose the option to Use an Existing View (.dvx) and click Browse to select the googledirectory.dvx file.
-
Click OK.
-
Click Ok to complete the wizard and OK again to exit the confirmation.
To view the schema associated with the googledirectory data source and default virtual view, go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab and open the schema named googledirectory. The objects that can be virtualized from Google are described in this file. To create a new virtual view, use the View Designer sub-tab on the Context Builder tab and load the googledirectory.orx file. For details on using View Designer, see the RadiantOne Context Builder Guide.
You can browse the runtime virtual view from the Main Control Panel > Directory Browser tab. An example is shown below.
Figure 40: Sample Virtual View of Google Directory
Okta Universal Directory
RadiantOne includes a default virtual view for Okta located at <RLI_HOME>/vds_server/dvx/okta2.dvx. You can use the default view by configuring the connection to your Okta directory as described in the Configure RadiantOne Custom Data Source section and mounting it in the RadiantOne Namespace. If you have custom attributes configured in your Okta directory that you would like to include in the virtual view, you can customize the virtual view with the steps outlined in Extend Virtual View with New Okta Attributes, and Modify the Virtual View.
The virtual view can be aggregated and/or joined with virtual views from other identities silos; however this extended configuration is out of the scope of this document.
Configure RadiantOne Custom Data Source
-
Navigate to the Main Control Panel > Settings tab > Server Backend section > Custom Data Sources > oktaclient
-
On the top, click Edit.
-
In the Custom Properties section, select the url property and click Edit.
-
Enter the url required to connect to your Okta Rest service (e.g. https://myco.oktapreview.com/) and click OK.
-
In the Custom Properties section, select the apitoken property and click Edit.
-
Enter the apitoken obtained from your Okta Admin and click OK.
-
(Optional) If you have enabled the Advanced Search option in Okta, you can leverage it by creating a new property named “usesearch”. Click ADD and create a property named usesearch with a value of true like in the example shown below.
Figure 41: Creating the usesearch property
-
Click OK.
-
(Optional) If your company requires API calls to be made through a Web Proxy Server, click ADD and create a property named “proxy” with a value that points to the proxy server and port (e.g. rli.vip.proxy.com:9090).
-
Click OK.
-
(Optional) If you configured a “proxy” property and indicated the Web Proxy Server and port, and SSL is required, click ADD and create a property named “proxyssl” with a value of true.
-
Click OK.
-
Click Save.
Figure 8.42: Okta Custom Data Source Configuration
-
From the Main Control Panel -> Directory Browser tab, navigate to the location where you’ve mounted your virtual view (okta2.dvx).
Figure 43: Sample Run Time Virtual View from Okta Universal Directory
(Optional) Extend Virtual View with New Okta Attributes
Virtual views are based on a metadata configuration file containing default attributes describing users and groups in the Okta directory. If you have custom attributes in Okta that you would like to expose in your virtual view, follow the steps in this section to add them.
-
Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.
-
Click .
-
On the Custom Schemas tab, select okta2. Click Open. The okta2.orx file opens.
-
To add a new attribute for users in the schema, expand the branches under okta2 > Objects > Tables > users > Fields. For groups, expand the branches under okta2 > Objects > Tables > groups > Fields.
-
Right click on Fields and select Add New Attribute.
Figure 44: Add New Attributes
-
The ‘Add New Attribute’ opens. The Name of the attribute needs to be prefixed by ‘profile-’. For example, a custom attribute ‘uid’ in okta, should be entered as profile-uid.
Figure 8.45: Attribute Name
-
Click OK.
-
Repeat this process to add all the required custom attributes.
-
Click .
(Optional) Modify the Virtual View
If you have modified the metadata as described in Extend Virtual View with New Okta Attributes, update the virtual view to reflect the changes.
-
Go to the Main Control Panel > Context Builder tab > View Designer sub-tab.
-
Click .
-
Select okta2 and click OK.
-
In the virtual view definition, expand below object=users and select the users content level.
-
Select the Attributes tab on the right.
-
Select the custom attribute from the list on the left and then use the button to map the attribute to the list on the right. Attributes shown in the right column are returned in the virtual view. If you want the attribute to display with a different name, click in the Virtual Name column and enter the name. In the example below, a custom attribute named profile-rli is added to the virtual view and has a virtual name of rli.
Figure 46: Virtual View Definitions – Attributes
-
To expose all Okta attributes in the virtual view, click the button.
-
If you’ve added custom attributes for groups, In the virtual view definition, navigate to okta2 > object=groups.
-
Select the groups content node.
-
Select the Attributes tab on the right.
-
Select the custom attribute from the list on the left and then use the button to map the attribute to the list on the right. Attributes shown in the right column are returned in the virtual view. If you want the attribute to display with a different name, click in the Virtual Name column and enter the name.
-
Click .
SailPoint IIQ
RadiantOne can virtualize the SailPoint Identity IQ database via SCIM. The configuration is described in this section.
Configure RadiantOne SCIM Data Source
-
In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom data Sources section, select scimclient2 and click Edit.
NoteIf you are already using the scimclient2 custom data source to virtualize a SCIM backend, click the Clone button to make a copy that you can work with for SailPoint to avoid impacting your existing configuration.
-
Click Advanced Edit.
-
Select the url property and click Edit.
-
Enter the value matching your SailPoint SCIM service. The syntax is:
http://<SailPointServer>:<port>/identityiq/scim/v2
-
Click OK.
-
Select the username property and click Edit.
-
Enter your SailPoint username (e.g. spadmin).
-
Click OK.
-
Select the password property and click Edit.
-
Enter the password associated with your SailPoint user name.
-
Click OK.
NoteIf OAuth is used for authentication, you do not need the username and password properties. Configure the oauthurl, oauthclientid, and oauthclientsecret properties instead. This is described in OAuth Authentication.
-
Select the replaceonupdate property (add if it doesn’t exist). Set the value to true. This is required because the SailPoint SCIM interface doesn’t support standard update (PATCH) operations and requires a replace operation (PUT) instead.
NoteFor SCIM servers that do not support PATCH operations, FID sends a PUT request to the SCIM Server, which replaces the entry.
-
Click Save.
OAuth Authentication
For RadiantOne to support OAuth authentication in the SCIM requests to SailPoint, you must enable API Authentication in the SailPoint Admin Console.
The steps below provide general guidance and may not reflect the latest SailPoint interface. For more detailed configuration steps, refer to the SailPoint documentation.
-
Log into the SailPoint Admin Console as an administrator.
-
Go to Global Settings.
Figure 8.47: SailPoint Global Settings
-
Click API Authentication
Figure 8.48: SailPoint API Authentication
-
Click Create.
-
Enter a unique Client Name.
-
Select the proxy user to associate with the client.
-
Click Save.
-
Take note of the Client Id and the Secret (click to reveal the secret).
Figure 8.49: SailPoint OAuth Client Configuration
-
In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom Data Sources, select the configuration associated with SailPoint and click Edit.
-
Click Advanced Edit.
-
Click Add.
-
Enter oauthurl for the Name property and enter the SailPoint Token Endpoint for the value. The syntax is:
http://
-
Click OK.
-
Click Add.
-
Enter oauthclientid for the Name property and provide the Client ID value associated with your SailPint OAuth client configuration.
Figure 8.50: Sample Client ID Value
-
Click OK.
-
Click Add.
-
Enter oauthclientsecret for the Name property and provide the Client Secret value associated with your SailPoint OAuth client configuration.
-
Click OK.
-
Click Save.
Configure RadiantOne Virtual View
The Context Builder can be used to extract the metadata/schema from SailPoint and build a virtual view.
-
Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.
-
Click .
-
Select the SCIM v2.0 option and click Next.
-
Select the data source associated with SailPoint from the drop-down list and click Next.
Figure 8.51: SCIM v2 Schema Extraction
-
Select the objects to extract and click Next. You can select all objects at this step because the virtual view definition can be customized to include only desired objects and attributes.
-
Enter a file name for the schema and click Create Schema. The extracted schema opens in Schema Manager. Expand below each object to see the corresponding attributes.
-
From the Context Builder tab > View Designer sub-tab, click .
-
Enter a name for the virtual view.
-
Click Select to choose the file containing the SailPoint schema on the Custom tab and click OK*.
NoteThe virtual view definition can be customized as needed. The steps in this guide create a basic virtual view.
-
Click OK to create the view.
-
Select the file name in the tree view on the left and click New Label on the right.
-
Enter object for the Level Type and user for the value.
-
Click OK.
-
Select the object=user node in the tree view on the left and choose New Content on the right.
-
Select the Users object and click OK.
Figure 52: SailPoint Virtual View
-
For the selected users content node, click the Attributes tab.
-
Click to expose all available attributes in the virtual view.
Figure 43: SailPoint Attributes Available in the Virtual View
-
Click .
-
Mount this virtual view below a naming context, from the Main Control Panel > Directory Namespace tab.
-
To test the virtual view, go to the Main Control Panel > Directory Browser tab and navigate below the naming context where you mounted the virtual view. Your SailPoint users are shown.
Figure 54: Sample Run Time Virtual View from SailPoint
Configure Virtual View of Users with Groups/Entitlements
To virtualize SailPoint users with their entitlements/groups returned in the entry, you must use the Account object/resource instead of the Users object. This section describes how create a basic virtual view of accounts from SailPoint.
-
From the Context Builder tab > View Designer sub-tab, click .
-
Enter a name for the virtual view (e.g. sailpointscimclient2accounts).
-
Click Select to choose the file containing the SailPoint schema on the Custom tab and click OK.
-
Click OK to create the view.
-
Select the file name in the tree view on the left and click New Label on the right.
-
Enter Object for the Level Type and Accounts for the value.
-
Click OK.
-
Select the Object=Accounts node in the tree view on the left and choose New Content on the right.
-
Select the Accounts object and click OK.
-
On the Attributes tab, click to expose all available attributes in the virtual view.
NoteID is the only required attribute. However, any attribute that you want clients to use in a filter (when querying RadiantOne) must be defined for the object.
-
Click .
Figure 55: SailPoint Accounts Virtual View
-
Mount this virtual view below a naming context from the Main Control Panel > Directory Namespace tab.
-
To test the virtual view, go to the Main Control Panel > Directory Browser tab and navigate below where you mounted the virtual view. Your SailPoint accounts are shown. For each account, the groups attribute returns the groups/entitlements the user is associated with. An example is shown below.
Figure 8.56: Run Time Sample of SailPoint Accounts
PingOne Directory
RadiantOne can virtualize a PingOne Directory via SCIMv1. The configuration is described in this section. Configure RadiantOne SCIM Data Source
-
In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom data Sources section, select scimclient and click Edit.
NoteIf you are already using the scimclient custom data source to virtualize a SCIM backend, click the Clone button to make a copy that you can work with for PingOne to avoid impacting your existing configuration.
-
Select the url property and click Edit.
-
Enter the value matching your PingOne service.
-
Click OK.
-
Select the username property and click Edit.
-
Enter your PingOne directory user ID.
-
Click OK.
-
Select the password property and click Edit.
-
Enter the password associated with your PingOne user name.
-
Click OK.
-
Click Add.
-
Enter bodyauth for the property name with a value of true. This ensures that the authentication credentials (for authenticating users in the PingOne data source) are sent in the body of the request instead of in the URL. If this property is not present, the credentials are sent to PingOne in the URL.
Figure 57: Sample PingOne Custom Data Source
-
(Optional) RadiantOne (as a SCIM client) uses paging when communicating with the SCIM service (backend). The default page size is 500. You can customize the page size by adding a custom property named pagesize to the data source. Click Add and enter pagesize for the property name and the page size for the value.
Figure 58: Page Size Property for SCIM Backend
-
(Optional) If you want to connect to PingOne directory using OAuth 2.0, click Add and complete steps 15-22. Otherwise, skip to step 23.
-
Enter oauthurl for the Name property and enter the PingOne Token Endpoint for the value. The syntax is: https://directory-api.pingone.com/api/oauth/token
-
Click OK.
-
Click Add.
-
Enter oauthclientid for the Name property and provide the Client ID value associated with your PingOne OAuth client configuration.
-
Click OK.
-
Click Add.
-
Enter oauthclientsecret for the Name property and provide the Client Secret value associated with your PingOne OAuth client configuration.
-
Click OK.
-
Click Save.
Configure RadiantOne Virtual View
RadiantOne includes a default SCIM virtual view that can be used to virtualize PingOne Directory (<RLI_HOME>\vds_server\dvx\scimclient.dvx). The default data source associated with this virtual view is named scimclient. If you cloned the default scimclient custom data source to work with PingOne in the previous section, you can edit the default scimclient virtual view to use your custom data source.
-
Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.
-
Click .
-
On the Custom Schemas tab, select the scimclient.orx and click Open.
-
On the tree view on the left, right-click on scimclient and choose Edit Connection String.
-
Click Edit to select the appropriate custom data source.
Figure 59: Custom Data Source Associated with Virtual View
-
Click OK.
-
Click .
WarningYou can create a new virtual view instead of using the scimclient.dvx default one described in this section. However, you must first open scimclient.orx in Context Builder and Edit the Connection String to point to your appropriate custom data source. Otherwise, it continues to use the default custom data source named scimclient.
-
Mount this virtual view below a root naming context, from the Main Control Panel > Directory Namespace tab.
-
To test the virtual view, go to the Main Control Panel > Directory Browser tab and navigate below the naming context where you mounted the virtual view. Your PingOne user accounts are shown.
Figure 8.60: Sample Run Time Virtual View from PingOne Directory
AWS Cognito
This section describes how to virtualize AWS Cognito users and groups in RadiantOne using a default virtual view. Views created from AWS Cognito data sources are read-only, and binds are not supported. LDAP filters are also not supported. This means that when RadiantOne receives queries that contain filters from clients, those filters are not forwarded to AWS Cognito for processing.
To support LDAP filters, create a view of AWS Cognito and configure it for a persistent cache with periodic refresh. For information on creating your own views, refer to the Context Builder Guide. For information on configuring persistent cache with periodic refresh, refer to the RadiantOne Deployment and Tuning Guide.
To virtualize AWS cognito users and groups:
-
In AWS, make a note of the following values.
- Pool ID
- Access Key ID
- Secret Key
-
In the RadiantOne Main Control Panel, go to Settings > Server Backend > Custom Data Sources.
-
Select the awscognito data source and click Edit. The Edit AWS Data Source page displays.
-
Enter your AWS access key ID, secret access key, and region (optional).
-
Click the Advanced Edit button.
-
Click the Add button. The Add Custom Property window opens.
-
Name the property poolid. In the Value field, enter the AWS pool ID value.
-
Click OK.
-
Click the Add button again.
-
Name the property classname. In the Value field, enter: com.rli.scripts.customobjects.awscognito
Figure 8.61: AWS Cognito Custom Data Source
-
Click Save.
If a confirmation box displays the message “Connection to the data source backend failed, save anyway?”, click Yes**.
-
On the Directory Namespace tab, click the New Naming Context button.
-
Enter a unique naming context and select the Virtual Tree type.
-
Click Next. The Configure Virtual Tree window opens.
-
Select Use an existing view (.dvx).
-
Click Browse next to Select File from the Server. The Choose a file on the server window opens.
-
Select awscognito.dvx and click OK.
-
Click OK again. Click OK to close the New Virtual Tree confirmation window.
-
Click the Directory Browser tab.
-
Click the button.
-
Expand the new naming context. Expand Category=users and/or Category=groups. Verify that the naming context populated with your AWS users and groups.
Figure 8.62: Sample Virtual View of AWS Cognito Users and Groups