Virtual Views of Cloud Directories and Services

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.

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.

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

1. Log into Salesforce and go to Setup > Apps > App Manager and click New Connected App.

Figure 8. 1: Creating a Salesforce Connected App

1. Enter a name for the application, email to associate with the application and check the option to Enable OAuth Settings.
2. Enter a CallBack URL. RadiantOne doesn’t use this so the value doesn’t really matter. You can use: https://www.radiantlogic.com
3. Select the OAuth scopes that are applicable and click to add them.
4. Leave all other defaults and click Save.

Figure 8.2: Configuring Salesforce Connected App

1. After clicking save, you are warned about the 10-minute wait time. Click Continue.
2. Take note of the Consumer Key shown on the summary page. You need this value to configure RadiantOne.
3. 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 8.3: Sample Salesforce Connected App

Figure 8.4: Viewing Consumer Key and Secret for Connected App

Configure a RadiantOne SCIM Data Source

1. In the RadiantOne Main Control Panel -> Settings tab -> Server Backend -> Custom data Sources section, select scimclient and click Edit.

1. Click Add.
2. Enter oauthurl for the Name property and provide a value of https://login.salesforce.com/services/oauth2/token which is the Salesforce Token Endpoint.
3. Click OK.
4. Click Add.
5. Enter oauthclientid for the Name property and provide the Consumer Key value associated with your Salesforce Application.

Figure 8.5: Sample Consumer Key Value

1. Click OK.
2. Click Add.
3. Enter oauthclientsecret for the Name property and provide the Consumer Secret value associated with your Salesforce Application.
4. Click OK.
5. Select the url property and click Edit.
6. Enter the value matching your Salesforce SCIM service. The syntax is: https://<your_SCIMservice_url>/services/scim/v1

Figure 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

1. Click OK.
2. Select the username property and click Edit.
3. Enter your Salesforce username (email).
4. Click OK.
5. Select the password property and click Edit.
6. Enter the password (which is your password appended with the security token you received from Salesforce) associated with your Salesforce user name.
7. Click OK.
8. 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.

1. Go to the Main Control Panel > Context Builder.
2. Choose File > Open > Schema.
3. Select the scimclient.orx and click OK.
4. 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.

Figure 8.8: The Edit Connection String Option

1. Click “Edit” to select the appropriate custom data source.

Figure 8.9: Click Edit to select the appropriate custom data source

1. Expand the file name > Objects > Tables and right-click on Users.
2. Choose Edit Primary Key(s).

Figure 8.10: Editing Primary Key for SCIM Schema

1. Select the id attribute from the attributes list and use to move it to the column on the right.
2. Select the username attribute from the column on the right and use to move it to the attributes column on the left.

Figure 8.11: Setting Primary Key

1. Click Apply.
2. Click .

1. Click the View Designer tab.
2. Click .
3. Enter a name for the virtual view.
4. Click “Select” and browse to the salesforcescimclient file on the Custom Schemas tab and click OK.

Figure 8.12: Creating a Virtual View from Salesforce

1. Select the salesforcescimclient node on the left and choose New Label on the right.
2. Enter “object” for the Level type and “user” for the value.
3. Click OK.
4. Click object=user in the tree on the left and choose New Content on the right.
5. Select the Users object and click OK.

Figure 8.13: Salesforce Virtual View

1. For the selected users content node, click the Attributes tab.
2. Click to expose all available attributes in the virtual view.
3. Click . Keep the same name (e.g. salesforcescimclient).
4. To mount this virtual view in the RadiantOne namespace, do so from the Main Control Panel -> Directory Namespace tab.
5. 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 8.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.

1. On the Main Control Panel -> Settings tab -> Server Backend section, go to DB Data Sources.
2. On the right, click on radiantsalesforce and click Edit.

Figure 8.15: Salesforce Custom Data Source

1. Enter your Salesforce user email in the User property.
2. Enter your Salesforce user’s password (which is your password appended with the security token you received from Salesforce) in the Password property.
3. If you are connecting to a production instance of Salesforce, the URL value should be: jdbc:salesforce:

If you are connecting to a sanbox/dev instance of Salesforce, the URL value should be:

jdbc:salesforce:<sandboxURL>

e.g. jdbc:salesforce:https://test.salesforce.com/services/Soap/u/30.0

1. 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).
2. 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.
3. 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.

1. Log in to Salesforce with the account you will use to connect to Salesforce from RadiantOne.

2. In the top right header of the main page, locate the link with your name.

3. Click the down arrow and select My Settings.

4. On the My Settings Page expand Personal.

5. 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.

 

Create Azure AD Application

If you have not already created an application in Azure AD, you must do so prior to configuring RadiantOne.

1. In the Microsoft Azure portal associated with your Azure AD, click on Manage -> App Registrations and then the New Registration button.
2. Provide a name for the application.
3. Select the option for “Accounts in this organizational directory only” for the Supported Account Types.
4. You do not need to provide a Redirect URI.
5. Click Register. The registered app is displayed. Take note of the Application ID.

Figure 8.16: Azure AD Application

1. Click the application to access the specific settings.
2. Navigate to Certificates & Secrets.
3. In the Client Secret Section, click New Client Secret.

1. Enter a description, expiration and click Add .
2. Take note of the secret key value displayed.
3. Navigate to API Permissions and click Add a Permission.
4. 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.

1. Select Application permissions for the Type.
2. Enable Directory.Read.All for read-only access. If you want read/write access to the data, enable the Directory.ReadWrite.All access.

Figure 8.17: Azure AD Application Permissions

1. Click Add Permissions.
2. In the Configured Permissions section, click Grant Admin Consent.
3. Click Yes.

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 8.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 8.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 8.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 8.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.

1. On the Main Control Panel > Settings tab > Server Backend section, go to Custom Data Sources.
2. On the right, click either the graphapi or mgraph data source and click Edit.

Figure 8.22: Azure AD Custom Data Source

1. Select the username property and click Edit.
2. Enter the value of the Azure AD Application ID.
3. (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”.
4. Enter the Azure AD Application ID for the clientid property value and click OK.
5. Click Add and create a property named auth_cert_password.
6. Enter the value of your certificate password for the auth_cert_password property and click OK.
7. Click Add and create a property named auth_cert_path.
8. Enter the value of your certificate path for the auth_cert_path property and click OK.
9. Click Add and create a property named auth_tenant.
10. Enter the value of your azure AD tenant for the auth_tenant property and click OK.
11. Click Add and create a property named auth_type.
12. Enter the value access_token_with_certificate and click OK.
13. (Optional) If you are using a client secret instead of a certificate, select the password property and click Edit.
14. (Optional) If you are using a client secret instead of a certificate, enter the secret key associated with your Azure AD application.
15. 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).
16. Click OK.
17. Select the oauthURL property and click Edit.
18. 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).
19. Click OK.
20. Select the active property and click Edit.
21. Enter true to activate the data source.
22. Click OK.
23. 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.

1. Click OK.
2. (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.
3. 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).
4. Click OK.
5. (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.

1. 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.
2. 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.

Figure 8.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.

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 8.25: Group Members Returned with ObjectID in the DN

To add the memberoid property:

1. Navigate to the Main Control Panel > Settings > Server Backend > Custom Data Sources.
2. Select graphapi and click Edit.
3. Click Add.
4. Enter memberoid as the property name.
5. Enter true for the value.
6. Click OK.

Figure 8.26: Adding Memberoid Property

1. Click Save.
2. 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).
3. Right-click on the Users object and choose Edit Primary Key.
4. Define the Objectid attribute as the primary key and remove userPrincipalName.

Figure 8.27: Modifying Primary Key for Users Object

1. Click Apply.
2. Save the schema.
3. Open graphapi.dvx in Main Control Panel > Context Builder tab > View Designer sub-tab.
4. In the tree view on the left, below graphapi, expand Object=Users and select the users content node.
5. Click Delete to remove this old definition.
6. In the tree view on the left, below graphapi, click Object=Users and choose New Content on the right.
7. Select Users and click OK.
8. On the Attributes tab for this node, use to define specific attributes as part of the view, or click to define all attributes.

1. Click to save the virtual view.
2. 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.

To add the ignoremember property:

1. Navigate to the Main Control Panel > Settings > Server Backend > Custom Data Sources.
2. Select graphapi and click Edit.
3. Click Add.
4. Enter ignoremember as the property name.
5. Enter true for the value.
6. Click OK.

Figure 8.29: Adding Ignoremember Property

1. 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.

1. From the Main Control Panel > Settings tab > Server Backend -> Custom Data Sources, select graphapi and click .

2. Enter a data source name (e.g. graphapitenantb) and click Clone.

3. Click OK to exit the confirmation.

4. Select the new custom data source (e.g. graphapitenantb) and click Edit.

5. 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 8.30: Graphapi Schema 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 8.31: Copying the appId value

Once you have the appId, follow the steps below.

1. 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.
2. 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

1. Click Add.
2. Click Save.

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.

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.

1. On Main Control Panel > Context Builder tab > View Designer sub-tab, choose File > Open > View.
2. Select graphapi.dvx or mgraph.dvx and click OK.
3. In the Tree View, expand below the object you’ve added extension attributes for.
4. Select the content node associated with the object.
5. 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).

1. 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.

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 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.

To configure a mapping for the surname attribute:

1. On the Main Control Panel > Context Builder tab > View Designer sub-tab, click .
2. Select graphapi.dvx or mgraph.dvx and click OK.
3. 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.
4. Choose the Attributes tab.
5. Enter sn in the Virtual Name column for the surname attribute.
6. 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.

1. Navigate to <RLI_HOME>\vds_server\conf and edit ldapsechema_00.ldif.

2. 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' ).

3. Save the file.

To virtualize Google Directory, a Service Account on the domain must be set to enable the connection.

1. 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 or https://admin.google.com//AdminHome

1. Create a new project.
2. Click the new project and accept the default id if requested.
3. 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.
4. Go to “APIs & auth” > credentials.
5. 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

1. Verify that the service account appears in API Project -> Permissions.

1. Go to the Admin console and log in as an administrator for your domain.
2. Go to Security (if it does not appear on the dashboard/homepage, click “More controls” at the bottom).
3. In Security, click API reference and check “Enable API access”.

Figure 8.36: Enabling Google API Access

1. 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.
2. 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:

https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.orgunit,https://www.googleapis.com/auth/admin.directory.device.mobile,https://www.googleapis.com/auth/admin.directory.device.chromeos

1. Click “Authorize”. The service account is now entitled to view and manage all Directory data.

Figure 8.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.

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.

1. On the Main Control Panel > Settings tab > Server Backend section, go to Custom Data Sources.
2. On the right, click on googledirectory and click Edit.

Figure 8.38: Google Directory Custom Data Source

1. Select the domain property and click Edit.
2. Enter your domain name in the Domain parameter.
3. Select the service_account_p12_certificate property and click Edit.
4. Enter the full path to your certificate, including your certificate name and click OK.
5. In the Custom Properties, select the service_account_user property and click Edit.
6. Enter the value of the user account associated with the super admin role in your Google Directory and click OK.
7. In the Custom Properties, select the service_account_email property and click Edit.
8. Enter the value of the email account associated with your service account in the Google Directory and click OK.
9. Click Save.
10. 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.
11. 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.
12. Enter a new root naming context (e.g. o=googledirectory) and select the Virtual Tree option.

Figure 8.39: New Root Naming Context

1. Click Next.
2. Choose the option to Use an Existing View (.dvx) and click Browse to select the googledirectory.dvx file.
3. Click OK.
4. Click Ok to complete the wizard and OK again to exit the confirmation.

You can browse the runtime virtual view from the Main Control Panel > Directory Browser tab. An example is shown below.

Figure 8.40: Sample Virtual View of Google 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

1. Navigate to the Main Control Panel > Settings tab > Server Backend section > Custom Data Sources > oktaclient

2. On the top, click Edit.

3. In the Custom Properties section, select the url property and click Edit.

4. Enter the url required to connect to your Okta Rest service (e.g. https://myco.oktapreview.com/) and click OK.

5. In the Custom Properties section, select the apitoken property and click Edit.

6. Enter the apitoken obtained from your Okta Admin and click OK.

7. (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 8.41: Creating the usesearch property

1. Click OK.

2. (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).

3. Click OK.

4. (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.

5. Click OK.

6. Click Save.

Figure 8.42: Okta Custom Data Source Configuration

1. From the Main Control Panel -> Directory Browser tab, navigate to the location where you’ve mounted your virtual view (okta2.dvx).

Figure 8.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.

1. Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.

2. Click .

3. On the Custom Schemas tab, select okta2. Click Open. The okta2.orx file opens.

4. 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.

5. Right click on Fields and select Add New Attribute.

Figure 8.44: Add New Attributes

6. 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

7. Click OK.

8. Repeat this process to add all the required custom attributes.

9. 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.

1. Go to the Main Control Panel > Context Builder tab > View Designer sub-tab.

2. Click .

3. Select okta2 and click OK.

4. In the virtual view definition, expand below object=users and select the users content level.

5. Select the Attributes tab on the right.

6. 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 8.46: Virtual View Definitions – Attributes

7. To expose all Okta attributes in the virtual view, click the button.

8. If you’ve added custom attributes for groups, In the virtual view definition, navigate to okta2 > object=groups.

9. Select the groups content node.

10. Select the Attributes tab on the right.

11. 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.

12. Click .

 

RadiantOne can virtualize the SailPoint Identity IQ database via SCIM. The configuration is described in this section.

Configure RadiantOne SCIM Data Source

1. In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom data Sources section, select scimclient2 and click Edit.

1. Click Advanced Edit.
2. Select the url property and click Edit.
3. Enter the value matching your SailPoint SCIM service. The syntax is: http://<SailPointServer>:<port>/identityiq/scim/v2
4. Click OK.
5. Select the username property and click Edit.
6. Enter your SailPoint username (e.g. spadmin).
7. Click OK.
8. Select the password property and click Edit.
9. Enter the password associated with your SailPoint user name.
10. Click OK.

1. 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.

1. 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.

1. Log into the SailPoint Admin Console as an administrator.
2. Go to Global Settings.

Figure 8.47: SailPoint Global Settings

1. Click API Authentication

Figure 8.48: SailPoint API Authentication

1. Click Create.
2. Enter a unique Client Name.
3. Select the proxy user to associate with the client.
4. Click Save.
5. Take note of the Client Id and the Secret (click to reveal the secret).

Figure 8.49: SailPoint OAuth Client Configuration

9. In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom Data Sources, select the configuration associated with SailPoint and click Edit.

10. Click Advanced Edit.

11. Click Add.

12. Enter oauthurl for the Name property and enter the SailPoint Token Endpoint for the value. The syntax is:

http://<SailPointServer>:<port>/identityiq/oauth2/token

13. Click OK.

14. Click Add.

15. 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

16. Click OK.

17. Click Add.

18. Enter oauthclientsecret for the Name property and provide the Client Secret value associated with your SailPoint OAuth client configuration.

19. Click OK.

20. Click Save.

Configure RadiantOne Virtual View

The Context Builder can be used to extract the metadata/schema from SailPoint and build a virtual view.

1. Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.
2. Click .
3. Select the SCIM v2.0 option and click Next.
4. Select the data source associated with SailPoint from the drop-down list and click Next.

Figure 8.51: SCIM v2 Schema Extraction

1. 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.
2. 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.
3. From the Context Builder tab > View Designer sub-tab, click .
4. Enter a name for the virtual view.
5. Click Select to choose the file containing the SailPoint schema on the Custom tab and click OK*.

1. Click OK to create the view.
2. Select the file name in the tree view on the left and click New Label on the right.
3. Enter object for the Level Type and user for the value.
4. Click OK.
5. Select the object=user node in the tree view on the left and choose New Content on the right.
6. Select the Users object and click OK.

Figure 8.52: SailPoint Virtual View

1. For the selected users content node, click the Attributes tab.
2. Click to expose all available attributes in the virtual view.

Figure 8. 43: SailPoint Attributes Available in the Virtual View

1. Click .
2. Mount this virtual view below a naming context, from the Main Control Panel > Directory Namespace tab.
3. 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 8.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.

1. From the Context Builder tab > View Designer sub-tab, click .

2. Enter a name for the virtual view (e.g. sailpointscimclient2accounts).

3. Click Select to choose the file containing the SailPoint schema on the Custom tab and click OK.

4. Click OK to create the view.

5. Select the file name in the tree view on the left and click New Label on the right.

6. Enter Object for the Level Type and Accounts for the value.

7. Click OK.

8. Select the Object=Accounts node in the tree view on the left and choose New Content on the right.

9. Select the Accounts object and click OK.

10. On the Attributes tab, click to expose all available attributes in the virtual view.

11. Click .

Figure 8.55: SailPoint Accounts Virtual View

12. Mount this virtual view below a naming context from the Main Control Panel > Directory Namespace tab.

13. 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

RadiantOne can virtualize a PingOne Directory via SCIMv1. The configuration is described in this section. Configure RadiantOne SCIM Data Source

1. In the RadiantOne Main Control Panel > Settings tab > Server Backend > Custom data Sources section, select scimclient and click Edit.

2. Select the url property and click Edit.

3. Enter the value matching your PingOne service.

https://directory-api.pingone.com/api/directory

4. Click OK.

5. Select the username property and click Edit.

6. Enter your PingOne directory user ID.

7. Click OK.

8. Select the password property and click Edit.

9. Enter the password associated with your PingOne user name.

10. Click OK.

11. Click Add.

12. 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 8.57: Sample PingOne Custom Data Source

13. (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 8.58: Page Size Property for SCIM Backend

14. (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.

15. 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

16. Click OK.

17. Click Add.

18. Enter oauthclientid for the Name property and provide the Client ID value associated with your PingOne OAuth client configuration.

19. Click OK.

20. Click Add.

21. Enter oauthclientsecret for the Name property and provide the Client Secret value associated with your PingOne OAuth client configuration.

22. Click OK.

23. 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.

1. Go to the Main Control Panel > Context Builder tab > Schema Manager sub-tab.
2. Click .
3. On the Custom Schemas tab, select the scimclient.orx and click Open.
4. On the tree view on the left, right-click on scimclient and choose Edit Connection String.
5. Click Edit to select the appropriate custom data source.

Figure 8.59: Custom Data Source Associated with Virtual View

1. Click OK.
2. Click .

1. Mount this virtual view below a root naming context, from the Main Control Panel > Directory Namespace tab.
2. 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

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 virtualize AWS cognito users and groups:

1. In AWS, make a note of the following values.

• Pool ID
• Access Key ID
• Secret Key

2. In the RadiantOne Main Control Panel, go to Settings > Server Backend > Custom Data Sources.

3. Select the awscognito data source and click Edit. The Edit AWS Data Source page displays.

4. Enter your AWS access key ID, secret access key, and region (optional).

5. Click the Advanced Edit button.

6. Click the Add button. The Add Custom Property window opens.

7. Name the property poolid. In the Value field, enter the AWS pool ID value.

8. Click OK.

9. Click the Add button again.

10. Name the property classname. In the Value field, enter: com.rli.scripts.customobjects.awscognito

Figure 8.61: AWS Cognito Custom Data Source

11. Click Save.

12. On the Directory Namespace tab, click the New Naming Context button.

13. Enter a unique naming context and select the Virtual Tree type.

14. Click Next. The Configure Virtual Tree window opens.

15. Select Use an existing view (.dvx).

16. Click Browse next to Select File from the Server. The Choose a file on the server window opens.

17. Select awscognito.dvx and click OK.

18. Click OK again. Click OK to close the New Virtual Tree confirmation window.

19. Click the Directory Browser tab.

20. Click the button.

21. 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