Configure VCF SSO with modern identity provider for authentication and AD/LDAP for user-group provisioning

Products

• VCF Operations

Issue/Introduction

• Environments using modern identity providers like Okta, Entra etc have it as a cloud solution. In order to provision the users and groups from the Identity Provider into VCF, often the choice is between Just In-Time Provisioning(JIT) and SCIM (Add full form).
• For enterprises that choose SCIM, it works on a push model.
• This means that they have to open a port in their on-premise setup from the SCIM app in Identity Provider to push the users and groups into VCF.
• This often raises a security concern for some enterprises.

Environment

VCF Operations 9.0

Resolution

In order to resolve this, VCF Operations 9.0 introduced integrating with Active Directory through LDAP as a means of provisioning the user and groups. This means that customers will be configuring a modern identity provider either using OIDC or SAML. In asked to choose a protocol for user/group provisioning they can choose AD/LDAP. 

Things to consider

 

 

 

 

 

 

 

 

 

In the above situation, imagine an arbitrary user [email protected] is attempts authentication from IdP. The same user is provisioned from Active Directory. In order to ensure consistency, VMware Identity Broker, maintains a mapping of the user from both systems. 

 

If you have chosen OIDC as the authentication method, then, you need to provide the following values: 

Unique Identifier in OIDC Identity Provider - This is the identifier in your OIDC identity provider that is used to identify a user uniquely. In most cases, this is 'sub'. However, the value of 'sub' is not available in Active Directory, we we require a value common between your identity provider and active directory to map both system. Hence, you need to provide an unique identifier other than 'sub' for this field. Typically it could be emailID or employeeID or any custom attribute you may have. 

Unique Identifier in VCF Identity Broker -This is an attribute in the VCF Identity Broker which maps the unique identifier from OIDC Identity Provider to the Active Directory. Ensure that the value of this attribute from Active Directory is the same as the value of the unique identifier in OIDC Identity Provider. 

Example - In the above screenshots, we choose email as unique identifier in OIDC which is mapped to email in VCF Identity Broker. During the attribute mapping for Active Directory, it is important to map the email attribute of VCF Identity Broker to 'mail' from Active Directory. 

Unique Identifier in OIDC Identity Provider	Unique Identifier in VCF Identity Broker	Attribute Name in Active Directory	End result
sub	userName	sAMAccountName	Not possible. 'sub' cannot be the unique identifier from OIDC in this setup
username	userName	sAMAccountName	If the value of sAMAccountName from AD matches with the value of username from OIDC Identity Provider, authentication will be successful.
email	email	mail	If the value of mail from ADmatches with the value of email from OIDC Identity Provider, authentication will be successful.
custom-acme-empID	employeeID	employeeID	If the value of employeeID from AD matches with the value of custom-acme-attribute from OIDC Identity Provider, authentication will be successful.
username	firstName	given_name	No. username from OIDC identity provider is unlikely to match given_name from AD.

 

Important

1. Ensure that the unique identifier in VCF Identity Broker is mandatorily mapped to an attribute name from Active Directory
2. Ensure that the value of the unique identifiers from both the systems are equal