Identity & Access Management with VMware’s vRealize Automation and Forgerock’s OpenAM

In this blog post I’ll start with the big picture for the IAM target architecture in Swisscom, how we want to apply it to our Enterprise Cloud 2.0 with vRA, setting up the scene for our proof of concept with OpenAM as Identity Broker, detailed set up instructions and the list of planned activities and open points towards our suppliers.

In this blog post we’ll start with a big picture of the Identity & Access Management (IAM) target architecture at Swisscom.  As part of a proof of concept with OpenAM as Identity Broker (IDB), we’ll implement this architecture in our vRealize based Enterprise Cloud (EC). In the following, we’ll describe the overall setup, provide detailed configuration instructions and conclude with an outlook on planned activities and open points.

Motivation

In order to provide the foundation for a uniform IAM across different distribution channels and service providers (SP), Swisscom is building the “One Identity Broker“: A central point for federation to all customer and internal identity providers (IDP).

The following illustration depicts the target architecture. The „One IDB“ federates access to multiple customer active directories and enables centralized authentication. In this example, vRealize Automation (vRa) is using the „One IDB“ as a single source for authenticating all cloud users.

The key requirement for multi-enterprise multi-tenancy with vRealize Automation (vRa) is to federate multiple IDPs. The goal is to store the data of each IDP in distinct areas of our OpenDJ LDAP server in order to map the specific user base to the according tenants in vRa. Terrific, right?

The user will login only once (using two-factor authentication) in the portal according to his distribution channel. From there, he has Access to all Swisscom services using Single Sign On (SSO). In the EC product the solution enables access to the state-of-the-art Swisscom EC Portal and the older integrated vRA Portal (for expert mode). API access will be granted by OAuth 2.0.

Proof of Concept

In order to achieve the required isolation of the data from multiple IDPs we have set up this simple structure for our proof of concept:

So dc=kundeA,dc=cloudlab,dc=local is the base DN for customer A, whereas dc=kundeB,dc=cloudlab,dc=local is the container for the IDP of customer B. For the proof of concept, we kept the attributes for a user very simple:

dn: uid=S-1-5-21-2816643773-1283798656-1629251661-1105,ou=people,dc=kundeA,dc
 =cloudlab,dc=local
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: inetuser
objectClass: top
givenName: Hans
inetUserStatus: Active
uid: S-1-5-21-2816643773-1283798656-1629251661-1105
cn: Hans Muster
sn: Muster
userPassword: {SSHA}************************************
mail: hans.muster@kundea.org
groups: CloudUser
groups: Domain Users

node comment
Customer A adfs1.customer.local (AD and ADFS on 1 server)
Customer B ad.cloudlab.local /adfs.cloudlab.local (AD and ADFS for our LAB environment)
One IDB openam.cloudlab.local / opendj.clouldlab.local
SC Portal AngularJS Web Application on Swisscom’s Application Cloud

 

Roles in SAML-Federation (see numbers in the diagram above):

  • Customer ADFS are IdPs (1)
  • OpenAM is both, SP (2) with ADFS  and IdP (3) with vRA
  • vRA is SP (4) with OpenAM

The Portal is an OAuth client for vRA.

Set up ADFS for federation with OpenAM

This is a common use case and is already well documented (by forgerock):

https://wikis.forgerock.org/confluence/display/openam/OpenAM+and+ADFS2+configuration

https://wikis.forgerock.org/confluence/display/openam/ADFS+3+(Windows+2012+R2)+and+OpenAM+12

Setup OpenAM Idp

We have set up 2 realms for customer A and B.

In this view you can see the federations for customer A (/Kunde A) already set up. OpenAM has both roles, SP and IDP in the second row. The fifth row is tenant SYS in vRA set up as SP. The following screen shots describe the most important settings and the pitfalls we encountered during set up. The set up process in overall straightforward and relies on default parameters. Encoutered issues are pointed out.

This screenshot shows a pitfall you might want to avoid during set up of OpenAM as IDP for vRA:

Take care to enter an attribute mapping in the NameID Value Map: just put “=mail” at the end, especially for the “transient” format. If you don’t do this, OpenAM tries to generate a unique ID for each user that should be written at the service provider side. vRA does not accept the IDP to enforce data updates. With “mail” as identifier, OpenAM takes the mail address (in our case the user principal name – UPN) and does not enforce an update.

Setup Data Synchronization OpenDJ ->  vRA

On vRA side it is best to set up the LDAP Synch first because it will be referenced during the Identity Provider set up.

This is how it looks if a directory is already defined in vRA.

Just enter Directory Name, Server Host and Port. Change the custom directory search attribute to “mail”. The use of the distinguishedName (or dn) still remains a miracle to me 🙂

In the bottom part of the form, we changed ObjectUuid to “uid” (OpenDJ) and the distinguished name to “distinguishedName”. We had a lot of issues with this attribute until we added “distinguishedName” explicitly as attribute to the user object in OpenDJ. An extension of the OpenDJ schema was necessary for that. One could assume that the “dn” is a synthetic attribute that shouldn’t have to be specified at all. After having compared with active directory, where “distinguishedName” is contained and updated automatically, we simply added it. Problem solved!

Attention: Per default the administrator of OpenDJ is called “Directory Manager” and is put on a node where searches with subtree scope are not allowed. VMware’s implementation of the OpenLDAP search does not seem to like spaces in the user name of the bind user. Consequently, we created a new administrator user in the bind configuration.

An additional issue we faced is the member attribute: we have to find a way to synch the groups with OpenDJ first.

We are still working on a solution for the just-in-time provisioning.

Here you can do the mapping between source and target attributes. Again the issue with “distinguishedName” popped up. The rest of the configuration is trivial.

The mapping of users and groups is omitted. We used the following dns:

ou=people,dc=kundeA,dc=cloudlab,dc=local for the users and
ou=groups,dc=kundeA,dc=cloudlab,dc=local for the groups.

After successful setup the directory can be synched and you should have all users and groups locally in vRA for entitlements or assigning roles. You can search them at Administration | User & Groups | Directory Users & Groups.

Important Update on „distinguishedName“  (2.6.2018)

OpenDJ is allowing a maximum of 1000 nodes on an unindexed query per default. „distinguishedName“ currently is an attribute that is not indexed.

We got the following exception: „javax.naming.NoPermissionException: [LDAP: error code 50 – You do not have sufficient privileges to perform an unindexed search]“

We have overcome this limitation by granting the right to perform unlimited unindexed queries to the service account vRA is using. The following steps are needed for this solution approach:

Create a file „add-unindexed-search-privilege.ldif“

add-unindexed-search-privilege.ldif
dn: <bind-dn-of-service-account>
changetype: modify
add: ds-privilege-name
ds-privilege-name: unindexed-search

Apply it to the service account:

/opt/opendj/bin/ldapmodify -h "`hostname`" -p "10389" -D "cn=Directory Manager" -w "set the password here" --filename /root/add-unindexed-search-privilege.ldif

Hint: consider indexing „distinguishedName“

 

Setup OpenAM as Identity Provider for vRA

This is how it looks if you have already configured an external identity provider in vRA.

This is the first part of the definition, just enter a reasonable name and add the meta data of the IDP you want to use. As we have self signed certificates on all servers in the lab we could not directly use the URL. But calling the export meta data URL of OpenAM will open the XML (see sample data) in the browser.

https://openamserver:8443/openam/saml2/jsp/exportmetadata.jsp?entityid=https://openamserver:8443/openam&realm=/KundeA

After pressing “Process IDP Metadata” you’ll get immediate feedback. If the XML is valid, you can continue with the next settings:

Here the NameID format “transient” has to be set to “email” and the optional ID policy to “transient”. The users are synched from the previously set up directory. Regarding the network ranges we didn’t have this much of a choice 😉

This is the last part of the IDP configuration: Here you have to press on the green plus to add an authentication method. We are using „passwordProtectedTransport“.

Very important: Download the SAML metadata needed to set up the remote service provider in OpenAM.

In order to activate the newly created IDP you have to add a policy. You will have to rearrange the order of the policies by dragging – yes, it works! – the new policy right to the top.

Attention: From this moment on the IDP is activated and you will not have access unless you have configured a administrator user from this IDP. However, we found some workarounds to fall back to the built-in IDP:

  1. Login to the default tenant by switching to the built in IDP. Logout and switch to the tenant with the external IDP. You should be able to login with the built-in IDP now.
  2. Disable the external IDP as long as you have access by selecting the IDP and hitting the button “Disable”
  3. Disable the external IDP by switching the status in the database to the value “2” = disabled.

Register vRA as remote service provider in OpenAM

Select the right realm and choose „Configure SAML v2 provider“.

vRA will act as a remote service provider.

Here you can upload the XML that you have previously downloaded at the end of the external IDP definition in vRA (SAML metadata).

That’s it! We have successfully defined a SAML federation between vRA and OpenAM.

Test the installation

If you login to the tenant with this configuration  (in our case /vcac/org/sys) you will notice that the third party IDP has taken control: You get redirected to OpenAM and from there to the IDP of this realm. For customer A in our PoC set up to adfs.customer.local.

Hopefully Vreni@customer.local is defined as administrator within the tenant in vRA.

OAuth 2.0

With the support of Paul Kennedy, Chief Functional Architect atVMware, we found the documentation for the OAuth support of VMware’s Identity Manager on Github. Unfortunately, the documentation is written for the standalone Identity Manager and is not suited for the embedded version that comes with vRA. Nevertheless, we noticed similar URLs during login on the vRA web portal and it took us only a few tries to figure out how this works in vRA. As there is no management frontend deployed with the embedded version, it was a bit of research work to find out how to register a valid OAuth client in vIDM of vRA.

The OAuth Flow and the registration of a client on the management interface is nicely described here. We only describe the parts that are specific for the embedded vIDM. Further documentation can be found via the excellent VMware API explorer.

Login

POST /SAAS/t/SYS/API/1.0/REST/auth/system/login HTTP/1.1
Host: vraserver
Content-Type: application/json
Accept: application/json; charset=utf-8
Cache-Control: no-cache
Postman-Token: cbd4648e-98e7-5a5a-fd12-cc5ee531a07c
 { "username": "sys_admin", "password": "*************", "organization": "sys", "issueToken": "true"}

In the reply you will find a token that has to be used in the authorization header:

{  "id": null,  "sessionToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNDc4NGM4Zi0zNTgxLTRiZjgtOTRiOC1jMTFmNTkyNmI0MzgiLCJwcm4iOiJzeXNfYWRtaW5AU1lTIiwiZG9tYWluIjoidnNwaGVyZS5sb2
NhbCIsInVzZXJfaWQiOiIyNDciLCJhdXRoX3RpbWUiOjE0ODY5MjU3NjUsImlzcyI6Imh0dHBzOi8vdnJhMi5jbG91ZGxhYi5sb2NhbC9TQUFTL3QvU1lTL2F1dGgiLCJhdWQiOiJodHRwczovL3ZyYTI
uY2xvdWRsYWIubG9jYWwvU0FBUy90L1NZUy9hdXRoL29hdXRodG9rZW4iLCJjdHgiOiJbe1wibXRkXCI6XCJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZ
FByb3RlY3RlZFRyYW5zcG9ydFwiLFwiaWF0XCI6MTQ4NjkyNTc2NSxcImlkXCI6MTY0fV0iLCJzY3AiOiJwcm9maWxlIGFkbWluIHVzZXIgZW1haWwiLCJpZHAiOiIwIiwiZW1sIjoiY2hyaXN0b3BoLnN
jaG55ZGVyQHN3aXNzY29tLmNvbSIsImNpZCI6IiIsImRpZCI6IiIsIndpZCI6IiIsImV4cCI6MTQ4NjkyNzU2NSwiaWF0IjoxNDg2OTI1NzY1LCJzdWIiOiI1NzVhMGM5ZS1kOTFiLTQ3MDUtYjliMS04ZWM
yYjY4ZjhmMjgiLCJwcm5fdHlwZSI6IlVTRVIifQ.iVt_EwOB6PlWj2v94ugWK-zlYxzxFm9UggfMSLuWSGXyPA8VG2YEUBX3XKIJdETTQOOsgWvTKar-4h9GQkM92IVLBjdxmPYkhz-HFjNVM5tPl1p6ZWFIRwi7o4bIk_4KKQwYttY9eaX-mtVMKQbG8O_B53on_gocOud-7-uLC6Y",  "firstName": null,  "lastName": null,  "admin": false,  "serverUrl": null,  "signingCert": null}

Register Client

POST /SAAS/jersey/manager/api/oauth2clients HTTP/1.1
Host: vraserver
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNDc4NGM4Zi0zNTgxLTRiZjgtOTRiOC1jMTFmNTkyNmI0MzgiLCJwcm4iOiJzeXNfYWRtaW5AU1lTIiwiZG9tYWluIjoidnNwaGVyZS5sb2NhbCIsInVzZXJfaWQiOiIyNDciLCJhdXRoX3RpbWUiOjE0ODY5MjU3NjUsImlzcyI6Imh0dHBzOi8vdnJhMi5jbG91ZGxhYi5sb2NhbC9TQUFTL3QvU1lTL2F1dGgiLCJhdWQiOiJodHRwczovL3ZyYTIuY2xvdWRsYWIubG9jYWwvU0FBUy90L1NZUy9hdXRoL29hdXRodG9rZW4iLCJjdHgiOiJbe1wibXRkXCI6XCJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydFwiLFwiaWF0XCI6MTQ4NjkyNTc2NSxcImlkXCI6MTY0fV0iLCJzY3AiOiJwcm9maWxlIGFkbWluIHVzZXIgZW1haWwiLCJpZHAiOiIwIiwiZW1sIjoiY2hyaXN0b3BoLnNjaG55ZGVyQHN3aXNzY29tLmNvbSIsImNpZCI6IiIsImRpZCI6IiIsIndpZCI6IiIsImV4cCI6MTQ4NjkyNzU2NSwiaWF0IjoxNDg2OTI1NzY1LCJzdWIiOiI1NzVhMGM5ZS1kOTFiLTQ3MDUtYjliMS04ZWMyYjY4ZjhmMjgiLCJwcm5fdHlwZSI6IlVTRVIifQ.iVt_EwOB6PlWj2v94ugWK-zlYxzxFm9UggfMSLuWSGXyPA8VG2YEUBX3XKIJdETTQOOsgWvTKar-4h9GQkM92IVLBjdxmPYkhz-HFjNVM5tPl1p6ZWFIRwi7o4bIk_4KKQwYttY9eaX-mtVMKQbG8O_B53on_gocOud-7-uLC6Y
Content-Type: application/vnd.vmware.horizon.manager.oauth2client+json
Accept: application/vnd.vmware.horizon.manager.oauth2client+json
Cache-Control: no-cache
Postman-Token: 6c5ffde8-a96c-9281-10de-7c30d00f8c47
{
   "clientId" : "SC_Portal",
   "secret" : "mysecret",
   "rememberAs" : "SC_Portal",
   "authGrantTypes" : "authorization_code",
   "scope" : "email profile user napps openid",
   "redirectUri" : "https://ec-portal-dev.scapp.io",
   "refreshTokenTTL" : 525600,
   "displayUserGrant": false
}

replies the newly created client:

{
  "clientId": "SC_Portal",
  "secret": "***************",
  "scope": "email profile user napps openid",
  "authGrantTypes": "authorization_code",
  "redirectUri": "https://ec-portal-dev.scapp.io",
  "tokenType": "Bearer",
  "tokenLength": 32,
  "accessTokenTTL": 10080,
  "refreshTokenTTL": 525600,
  "rememberAs": "SC_Portal",
  "resourceUuid": null,
  "displayUserGrant": false,
  "internalSystemClient": false,
  "activationToken": null,
  "strData": null,
  "_links": {
    "self": {
      "href": "/SAAS/jersey/manager/api/oauth2clients/SC_Portal"
    }
  }
}

OAuth login from web app

After these steps you will be able to use the registered client by calling the following URL:

https://vraserver/SAAS/t/SYS/auth/oauth2/authorize?response_type=code&client_id=SC_Portal&redirect_uri= https%3A%2F%2Fec-portal-dev.scapp.io&state=6h3qG9XkjGlfvGIee1Up2e39Cn5H0&scope=email%2Bprofile%2Buser%2Bnapps%2Bopenid

Next Steps

Action item 1 for VMware: JIT provisioning

As vRA needs all users and groups provisioned locally to enable assignment of permissions and vRA specific roles, vRA offers a periodic synchronization process with the attached directory server – minimal sync period is 1 hour. This leads to an inconvenience for users that have never logged in before or for roles that were never referenced before: After a initial login such a user would have to wait for the next scheduled synchronization until he is granted access to vRA. OpenAM/OpenDJ already have means to enforce a just-in-time (JIT) provisioning, but for vRA VMware is currently working on a solution.

A similar problem is the addition of new roles on the IDP: First new roles have to be detected and then to be provisioned as well. The usage of external roles for vRA has the huge advantage, that the permission model could then be controlled completely within the user and group store at customer’s side.

For the first phase we can live with a maixmal waiting time of 1 hour but we are already elaborating two work arounds to be sure that we have a solution in place:

JIT Provisioning of Groups

OpenAM enables developers to extend the system with handler classes. We are currently implementing such a handler, that detects new groups and publishes them to the LDAP user store (OpenDJ).

JIT Provisioning of Users and Groups (active propagation)

After having examined the API of the vIDM used in vRA we found the possiblity to actively trigger synchronization on demand. The same handler that is performing the JIT provisioning of the groups will – if any changes are detected – trigger the synchronization on vRA with the following calls:

Trigger Sync

POST /SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565/syncprofile/sync HTTP/1.1
Host: vraserver
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNDc4NGM4Zi0zNTgxLTRiZjgtOTRiOC1jMTFmNTkyNmI0MzgiLCJwcm4iOiJzeXNfYWRtaW5AU1lTIiwiZG9tYWluIjoidnNwaGVyZS5sb2NhbCIsInVzZXJfaWQiOiIyNDciLCJhdXRoX3RpbWUiOjE0ODY5MjU3NjUsImlzcyI6Imh0dHBzOi8vdnJhMi5jbG91ZGxhYi5sb2NhbC9TQUFTL3QvU1lTL2F1dGgiLCJhdWQiOiJodHRwczovL3ZyYTIuY2xvdWRsYWIubG9jYWwvU0FBUy90L1NZUy9hdXRoL29hdXRodG9rZW4iLCJjdHgiOiJbe1wibXRkXCI6XCJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydFwiLFwiaWF0XCI6MTQ4NjkyNTc2NSxcImlkXCI6MTY0fV0iLCJzY3AiOiJwcm9maWxlIGFkbWluIHVzZXIgZW1haWwiLCJpZHAiOiIwIiwiZW1sIjoiY2hyaXN0b3BoLnNjaG55ZGVyQHN3aXNzY29tLmNvbSIsImNpZCI6IiIsImRpZCI6IiIsIndpZCI6IiIsImV4cCI6MTQ4NjkyNzU2NSwiaWF0IjoxNDg2OTI1NzY1LCJzdWIiOiI1NzVhMGM5ZS1kOTFiLTQ3MDUtYjliMS04ZWMyYjY4ZjhmMjgiLCJwcm5fdHlwZSI6IlVTRVIifQ.iVt_EwOB6PlWj2v94ugWK-zlYxzxFm9UggfMSLuWSGXyPA8VG2YEUBX3XKIJdETTQOOsgWvTKar-4h9GQkM92IVLBjdxmPYkhz-HFjNVM5tPl1p6ZWFIRwi7o4bIk_4KKQwYttY9eaX-mtVMKQbG8O_B53on_gocOud-7-uLC6Y
Accept: application/vnd.vmware.horizon.v1.0+json
Content-Type: application/vnd.vmware.horizon.manager.connector.management.directory.sync.profile.sync+json
Cache-Control: no-cache

{"ignoreSafeguards":true}

should respond with 200 OK.

Check sync executions

GET /SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565/syncexecutions HTTP/1.1
Host: vraserver
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNDc4NGM4Zi0zNTgxLTRiZjgtOTRiOC1jMTFmNTkyNmI0MzgiLCJwcm4iOiJzeXNfYWRtaW5AU1lTIiwiZG9tYWluIjoidnNwaGVyZS5sb2NhbCIsInVzZXJfaWQiOiIyNDciLCJhdXRoX3RpbWUiOjE0ODY5MjU3NjUsImlzcyI6Imh0dHBzOi8vdnJhMi5jbG91ZGxhYi5sb2NhbC9TQUFTL3QvU1lTL2F1dGgiLCJhdWQiOiJodHRwczovL3ZyYTIuY2xvdWRsYWIubG9jYWwvU0FBUy90L1NZUy9hdXRoL29hdXRodG9rZW4iLCJjdHgiOiJbe1wibXRkXCI6XCJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydFwiLFwiaWF0XCI6MTQ4NjkyNTc2NSxcImlkXCI6MTY0fV0iLCJzY3AiOiJwcm9maWxlIGFkbWluIHVzZXIgZW1haWwiLCJpZHAiOiIwIiwiZW1sIjoiY2hyaXN0b3BoLnNjaG55ZGVyQHN3aXNzY29tLmNvbSIsImNpZCI6IiIsImRpZCI6IiIsIndpZCI6IiIsImV4cCI6MTQ4NjkyNzU2NSwiaWF0IjoxNDg2OTI1NzY1LCJzdWIiOiI1NzVhMGM5ZS1kOTFiLTQ3MDUtYjliMS04ZWMyYjY4ZjhmMjgiLCJwcm5fdHlwZSI6IlVTRVIifQ.iVt_EwOB6PlWj2v94ugWK-zlYxzxFm9UggfMSLuWSGXyPA8VG2YEUBX3XKIJdETTQOOsgWvTKar-4h9GQkM92IVLBjdxmPYkhz-HFjNVM5tPl1p6ZWFIRwi7o4bIk_4KKQwYttY9eaX-mtVMKQbG8O_B53on_gocOud-7-uLC6Y
Cache-Control: no-cache
Postman-Token: 31458672-cdca-8652-dd45-6e05d43bb2d7

sample response:

todo: insert response

Get Directory Configurations

GET /SAAS/jersey/manager/api/connectormanagement/directoryconfigs HTTP/1.1
Host: vraserver
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNDc4NGM4Zi0zNTgxLTRiZjgtOTRiOC1jMTFmNTkyNmI0MzgiLCJwcm4iOiJzeXNfYWRtaW5AU1lTIiwiZG9tYWluIjoidnNwaGVyZS5sb2NhbCIsInVzZXJfaWQiOiIyNDciLCJhdXRoX3RpbWUiOjE0ODY5MjU3NjUsImlzcyI6Imh0dHBzOi8vdnJhMi5jbG91ZGxhYi5sb2NhbC9TQUFTL3QvU1lTL2F1dGgiLCJhdWQiOiJodHRwczovL3ZyYTIuY2xvdWRsYWIubG9jYWwvU0FBUy90L1NZUy9hdXRoL29hdXRodG9rZW4iLCJjdHgiOiJbe1wibXRkXCI6XCJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydFwiLFwiaWF0XCI6MTQ4NjkyNTc2NSxcImlkXCI6MTY0fV0iLCJzY3AiOiJwcm9maWxlIGFkbWluIHVzZXIgZW1haWwiLCJpZHAiOiIwIiwiZW1sIjoiY2hyaXN0b3BoLnNjaG55ZGVyQHN3aXNzY29tLmNvbSIsImNpZCI6IiIsImRpZCI6IiIsIndpZCI6IiIsImV4cCI6MTQ4NjkyNzU2NSwiaWF0IjoxNDg2OTI1NzY1LCJzdWIiOiI1NzVhMGM5ZS1kOTFiLTQ3MDUtYjliMS04ZWMyYjY4ZjhmMjgiLCJwcm5fdHlwZSI6IlVTRVIifQ.iVt_EwOB6PlWj2v94ugWK-zlYxzxFm9UggfMSLuWSGXyPA8VG2YEUBX3XKIJdETTQOOsgWvTKar-4h9GQkM92IVLBjdxmPYkhz-HFjNVM5tPl1p6ZWFIRwi7o4bIk_4KKQwYttY9eaX-mtVMKQbG8O_B53on_gocOud-7-uLC6Y
Cache-Control: no-cache
Postman-Token: faa359a5-7b7a-ed3a-fb1d-6e9975b6259c

sample response:

{
    "items": [
        {
            "type": "OPEN_LDAP",
            "name": "kundea.opendj",
            "directoryId": "061fc4b4-ca07-411f-a7f9-6f12efc58565",
            "userstoreId": "36d06a78-88cc-4114-8e6b-4a092f058213",
            "countDomains": 1,
            "deleteInProgress": false,
            "syncConfigurationEnabled": true,
            "_links": {
                "hw-sync": {
                    "href": "/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565/syncprofile/sync"
                },
                "hw-dir-connectors": {
                    "href": "/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565/connectors"
                },
                "hw-dir-sync-executions": {
                    "href": "/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565/syncexecutions"
                },
                "self": {
                    "href": "/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/061fc4b4-ca07-411f-a7f9-6f12efc58565"
                }
            }
        }
    ],
    "_links": {
        "self": {
            "href": "/SAAS/jersey/manager/api/connectormanagement/directoryconfigs"
        }
    }
}

With these calls it is possible to trigger the synch if we introduce a new dependency: the name of the directory (here: „kundea.opendj.cloudlab.local“) has to be known to the OpenAM handler. If we’re using a reasonable naming convention this should not be a big issue because „kundeA“ is also the name of the OpenAM realm in use for this case. We have already a first version of this implementation in place and we want to test this approach for very large user stores. This solution is highly dependent on the efficiency of the synch of a large LDAP database.

Action item 2 for VMware: usage of distinguishedName

We have to double check with VMware how the dn or distinguishedName attribute is accessed within vIDM. For us it does not make sense if we have to actively keep that attribute in our directory schema as AD does it. We could, however, solve the problem within our JIT-provisioning handler described above but we want to avoid any line of unnecessary code.

Action item for Forgerock: cloud native deployment of OpenAM/OpenDJ

As we’d like to move forward into the cloud native world we want to have such an important and widely used component („One IDB“) be deployable as cloud native application with all the advantages of operations, redundancy and resilience. We’re in contact with Forgerock to start a PoC on this topic asap.