Dean Flaming

Tech Curmudgeons

Dean Flaming

These are my technical notes and blog postings on Identity, Mobility, and More...

Cross Organization Identity Brokering Using VMware Identity Manager 3rd Party IdP Integration for Trust & SSO AuthN

The following is a rough draft on how the two disparate organizations with separate environments can be linked together for account/group sync in support of user SSO from either entity into the other.


Very Rough Flow Diagram

Problem (Business Use Case):
More and more customers are joining forces to work together either through mergers and acquisitions or as partnerships. With these mergers and partnerships, customers are needing to share resources. This now must be done through single sign-on mechanisms as industry security brokers are changing from on-premises (active directory) to cloud-based solutions. More importantly, customers are not wanting to go the legacy route of providing complex, 2-way active directory trusts, but rather wish to use cloud based, open standard, secure solutions which exist in the marketplace today.

Executive Summary:
Utilizing a Cross Organization Identity Brokering solution allows for disparate companies to became technology partners by providing a secure identity management solution between trusted partners which replicates only the necessary attributes of a user’s identity throughout in order to not only provide access to services, applications, and desktops from partner companies, but allow for the user to have a fully seamless, secure, single sign-on experience via their own VMware Identity Manager portal to all resources across partnered companies.

In addition, this also provides the partnered companies to ensure their own environments remain protected to the necessary levels as well as an easy way to separate linked resources, should the partnership dissolve.

What was Deployed and How:
See above image

Benefits
  1. Allows for users in either company (entity) to access applications, desktops, and services offered or made available by the other company / entity while still maintaining Single Sign-On functionality through their own company’s tenant.
  2. Allows for individual companies to securely provide access to resources they own or control to users in other "trusted" partner companies without creating and maintaining an Active Directory or other security broker trust relationship.
  3. Allows for automation of Identity synchronization through use of 3rd Party identity management solutions.
  4. Allows for designation of multiple security checkpoints within both companies to ensure a user is properly identified, authenticated, and authorized while maintaining security and SSO functionalities.
  5. In addition to SSO functionalities for all users across multiple entities, allows for a single, self-service portal to present all resources available to the user from across multiple tenants and providers.

Concerns (Blockers) and Necessities (Requirements):
  1. Radiant Logic VDS solution will create an amalgomized Directory based upon select users/groups and their defined attributes within each source AD.
  2. The combined users and potentially groups will become the VDS.
  3. Users within VDS will have a defined set of agreed upon attributes
    1. First name
    2. Last name
    3. Email
    4. UPN
    5. objectGUID
    6. NT Account Name (sAMAccountName)? - Some older applications need to utilize these for authentication into the app.
    7. Password??? - This might not be needed as 3rd party IdP trust will not use this but trusting services might still require it. Radiant Logic VDS can sync password but this means password policies will need to be an agreed upon standard between entities.
      1. Note: Horizon TrueSSO would eliminate the need for password sync if both sides used VMW Horizon.
    8. Source entity (ORG1 or ORG2 - can be automatically derived from email or UPN)
    9. Member of (or Group Membership).
    10. Etc. (phone, office location, etc.)
  4. VDS will be synced into local Active Directory domain in each entity environment.
    1. Example: VDS.local
    2. VDS to AD domain sync may need to be selective per entity in order to avoid duplicate entries.
      1. Example: ORG1 users synced into VDS from ORG1 domain, do not need to be synced into VDS.local AD domain as those won't be utilized anyways, and may potentially cause duplicate email and UPN entries between VDS.local and org1.local.
  5. Local 2-way trust between VDS.local and entity primary domain will exist to allow trusted services to perform Windows authentication (i.e. Horizon or Citrix session authentication).
  6. A manual 2-way domain trust with SID filtering may be needed to ensure user accounts from other entities do not have any additional access to other resources.
  7. Citrix will not fully support TrueSSO-like functionality and will prompt for a user password for current and immediate logins to Citrix via Workspace ONE.
    1. A password will only be prompted once for each ws1 login. If a user logs in to ws1 only once per day then a password prompt will only happen once per day if timeout settings are longer than that.
  8. Both Identity Manager tenants will need to trust each other. This is a standard SP to IdP trust between each Identity Manager.
  9. Admins in both entities will need to have deep links (i.e. Relay state links) of 3rd party IdP protected apps in order to properly define the same app in both.
    1. Example: App1 is horizon app in ORG2 domain. In order to properly display and allow for SSO for users from ORG1, App1 must be manually created in ORG1 Identity Manager as a 3rd party app and properly assigned.
    2. Note: Assignment of apps can be done either by dynamic groups or by synced groups. Further discovery on this may be needed but shouldn't be an issue.
  10. All customers replicating into VDS and utilizing replicated user accounts for SSO should have independent security audits to ensure all best practices and requirements are adhered to.


Outcomes:
Users will be able to login to their own organization tenant and maintain Single Sign-On access to protected resources across both environments.

Resources:


Technical Details
Domain Trust and SID Filtering:
  • Ensure we are not sharing SIDs across domains. A potential malicious administrator could get additional access to the other domain. This eliminates lateral movement of an exploited system. SID filter quarantining for external trusts.
  • Implement selective authentication across the trusts.
Authentication Setting
Interforest Trust Type
Description
Domain-wide Authentication
External
Permits unrestricted access by any users in the trusted domain to all available shared resources located in the trusting domain. This is the default authentication setting for external trusts.
Forest-wide Authentication
Forest
Permits unrestricted access by any users in the trusted forest to all available shared resources located in any of the domains in the trusting forest. This is the default authentication setting for forest trusts.
Selective Authentication
External and Forest
Restricts access over an external or forest trust to only those users in a trusted domain or forest who have been explicitly given authentication permissions to computer objects (resource computers) residing in the trusting domain or forest. This authentication setting must be manually enabled.


Active Directory Integrations:

Permissions required for joining Identity Manager to a domain:

1. On the org.local domain all users or a group of users from the vdsorg.local domain (i.e. a group or Domain Users or authenticated users - whichever contains all users of "OU=FID Users,DC=vdsorg,DC=Local") need read and authenticate access to the Connector computer account in the org.local domain.
2. On the vdsorg.local domain, read access to the whole vdsorg.local domain for the org.local bind user account used by VMware Identity Manager residing in org.local.
3. I don’t think this last one will be needed as this account is ONLY used to by VMware Identity Manager to join the vidm connector to the active directory domain (something which is already done), but I added it in my lab.
On the vdsorg.local domain, domain admin access on the vdsorg.local domain for the org.local admin account used by VMware Identity Manager residing in org.local.


TEST Process for BIND Permissions
  1. Open LDP (A.D. tool)
  2. Connect to other trust DC
  3. Bind to get login prompt
  4. Login as bind account from resource domain
  5. View Tree and select resource domain
  6. Double click


Tech Summit Session
Cross Org Identity Brokering with Workspace ONE (TS-GPPS-144)


Published by Dean Flaming on