This post will walk you through basics and the setup of a 3rd Party IdP within Identity Manager. For this blog post, we will be using two separate VMware Identity Manager tenants as this allows for documentation of both sides for demonstration purposes.
This post assumes either VMware Identity Manager 2.8.x on-premises tenant or newer, or a VMware Identity Manager SaaS tenant.
Index:
You will find the following topics within this post:
- The Basics
- 3rd Party IdP High Level Layout
- Configurations & Use Cases
- VMware Identity Manager as a 3rd Party Identity Provider to another Primary Identity Provider
- Another 3rd Party Identity Provider integrated with VMware Identity Manager
- Bidirectional Identity Provider Integrations
- Chaining More than 2 Identity Providers
- Logic Flows
- Setting up a 3rd Party IdP in VMware Identity Manager
- Resources
The Basics:
When setting up a 3rd party Identity Provider (IdP) with VMware Identity Manager, it is first important to understand the difference between Authentication and Authorization and which piece (i.e. “Who”) does what and when.
The basic logic flow when VMware Identity Manager is part of this starts with VMware Identity Manager acting solely as a Service Provider (it is providing a service with the application catalog for users to choose applications for launch). VMware Identity Manager can also act as a 3rd Party Identity Provider but in this initial authentication flow, it is just a simple service provider.
- The user browses to VMware Identity Provider.
- VMware Identity Manager contacts the Primary Identity Provider (the one doing the authentication)
- The Primary IdP requests the user enter their credentials. In Secure Addressable Markup Language (SAML) terms, this is the claim.
- The Primary IdP validates this claim against a security provider (in this case, Active Directory).
- The Primary IdP responds with an updated SAML assertion specific for the Service Provider allowing the user to utilize the Service Provider in question.
Figure 1 - Common logic flow for two Identity Providers.
For customers who are integrating with a 3rd party IdP such as Okta or Ping, it is important to first understand where the users will log in to (Which IdP will handle the Authentication) and where the applications are protected (Which IdP will hand the Authorization). These are major points of understanding and must be comprehended first before proceeding as these can be either of the Identity Providers. In the above (Figure 1) diagram - and in the following (Figure 2) diagram, we are showing VMware Identity Manager sitting in front of another Identity Provider, but these can be swapped as we will discuss in the next paragraphs.
Typically with VMware Identity Manager and Workspace ONE, VMware recommends the VMware Identity Manager / Workspace ONE portal be where a user goes first to start their authentication. This means, VMware Identity Manager is the Service Provider and the customer's other identity solution is the Identity Provider for VMware Identity Manager. This allows the most flexibility overall for customers. In this method, VMware Identity Manager is actually seen as the 3rd Party IdP to the IdP which is protecting the applications. In this method, it does not mean VMware Identity Manager cannot protect apps, it just means the IdP which is currently protecting apps is considered the "Primary Identity Provider (IdP)". The IdP where users login to is considered the 3rd Party IdP.
Figure 2 - VMware Identity Manager acting as the 3rd Party Identity Provider to another Primary Identity Provider
It should be clarified, this does not mean customers are forced into using VMware Identity Manager first in the user authentication process. As stated previously, with VMware Identity Manager and its support of 3rd party IdPs, customers have the flexibility of configuring this in various ways. This includes making VMware Identity Provider the Primary IdP (application protector) and other Identity Providers as 3rd party IdPs.
Figure 3 - VMware Identity Manager acting as the Primary Identity Provider supporting another 3rd Party Identity Provider
Configurations & Use Cases:
Setting up a 3rd Party IdP in Identity Manager can be done in both unidirectional and bidirectional fashions. Images of these can be seen above in Figure 2 and Figure 3.
- In a Unidirectional flow, authentication happens first on the IdP which processes user logins, then authorization of applications (app launches) is handled by the IdP which is protecting the applications.
- Using VMware Identity Manager as the User Authentication.
NOTE: See Figure 2 above.
- This is a good scenario for when a customer already has a 3rd party IdP in place such as Ping or Okta and this 3rd Party IdP is protecting applications already. VMware Identity Manager would then be inserted into the flow to handle User Authentication to the 3rd party IdP.
- PROS:
- Less/No work to reconfigure applications.
- All applications protected by the 3rd Party may be presented in VMware Identity Manager.
- CONS:
- Users education will be necessary to redirect users to the new Identity Manager interface for login.
- Can easily integrate other VMware solutions for SSO such as Horizon, ThinApp, Horizon Air, AirWatch, etc. as well as Citrix solutions.
- PROS:
- Using VMware Identity Manager as the User Authentication.
- Using VMware Identity Manager for Application Authorization.
NOTE: See Figure 3 above.- This is an alternate scenario for when a customer already has a 3rd party IdP in place. VMware Identity Manager would be inserted into the flow to handle application authorizations after the 3rd party IdP handled user authentication.
- PROS:
- Customers can keep their existing end user portal for authentication.
- It is possible to redirect to the VMware Identity Manager web portal for a better user experience.
- CONS:
- Cannot work with Workspace ONE unless 3rd Party IdP has an authentication exception rule to route all mobile requests to VMware Identity Manager.
- All SaaS Applications must be reconfigured to work with VMware Identity Manager.
- PROS:
- This is an alternate scenario for when a customer already has a 3rd party IdP in place. VMware Identity Manager would be inserted into the flow to handle application authorizations after the 3rd party IdP handled user authentication.
- Does support support Horizon/Horizon Air/Citrix integrations.
Figure 4 - VMware Identity Manager configured with another Identity Provider in a bidirectional IdP trust
- A Bidirectional flow is simply two Unidirectional flows where both IdPs handle User Authentication and App Authorization for the “respective" other IdP. The general scenario is if a user authenticates to either IdP, they can be automatically authenticated to the other IdP and all applications.
- While many environments may need to operate utilizing this configuration, customers may wish to eventually migrate to a single identity management and single sign-on solution for simplicity sake.
- PROS:
- End Users are authenticated once and SSO is used to process further authentications to other IdPs.
- Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager).
- All applications protected by the 3rd Party may be presented in VMware Identity Manager.
- Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager.
- Can work with Workspace ONE for all applications protected by VMware Identity Manager.
- CONS:
- Two user portals creating additional administrative overhead.
- Complex setup and configuration.
- PSO recommended for environment mapping.
- User education required.
- May not support or not fully support Horizon/Horizon Air/Citrix integrations.
- May require complex authentication policies on one or both identity providers.
- Chaining 3 or more Identity Providers (IdPs) is also an option. However, when approaching this option, one should determine whether it is more beneficial to chain in serial or in a star logic-flow form.
- Example: In a serial fashion (not shown on this slide), the 1st IdP authenticates users. A 2nd IdP protects applications and trusts the 1st IdP for authentication. The 3rd IdP protects other applications and trusts the 2nd IdP for authentication.
- This option would be slightly less complex than the next option during initial setup but potentially more administrative overhead. Additionally it is not as flexible as a star logic flow configuration.
- In a star logic-flow fashion, it would look something like this. Each of the VMware Identity Manager tenants authenticates users. The backend Primary IdP tenant protects applications and trusts each of the VMware Identity Provider tenants as 3rd party IdPs for authentication. The Primary IdP tenant protects other applications and trusts each of the VMware Identity Manager tenants for authentication.
- This option would be slightly more complex during initial setup but potentially much less administrative overhead assuming the same A.D. users and groups are synced across all IdPs. While some environments may have to operate with this configuration, typically this configuration would be recommended mainly for migrations.
- PROS:
- End Users are authenticated once and SSO is used to process further authentications to other IdPs.
- Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager being the first authentication point).
- All applications protected by the 3rd Party may be presented in VMware Identity Manager tenants.
- Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager.
- Can work with Workspace ONE for all applications protected by VMware Identity Manager.
- CONS:
- Multiple user portals creating additional administrative overhead.
- Complex setup and configuration requiring a high level of planning up front.
- PSO recommended for environment mapping.
- User education required.
- May not support or not fully support Horizon/Horizon Air/Citrix integrations.
- May require complex authentication policies on one or both identity providers.
- Application management may be complex until all tenants brought together.
- Example: In a serial fashion (not shown on this slide), the 1st IdP authenticates users. A 2nd IdP protects applications and trusts the 1st IdP for authentication. The 3rd IdP protects other applications and trusts the 2nd IdP for authentication.
Logic Flows:
When incorporating a 3rd party Identity Provider, logic flows are altered based upon the end user story changes.
In the case where VMware is linking to another Identity Provider which is protecting an application, VMware is seen as the “3rd Party Identity Provider” to the other “Primary Identity Provider” (it being the one protecting the applications). When doing this in conjunction to adding in Single Sign-On support for Horizon 6/7/Air/Hosted, ThinApp, Mobile Apps, or other solutions such as Citrix remote hosted desktops and apps with XenApp 5/6/7 and XenDesktop 7, VMware Identity Manager becomes the new, front-facing login portal for all users in order to provide a seamless end-user experience across all devices, applications, and services.
In the case where VMware Identity Manager is protecting applications such as Mobile apps but sits behind another Identity Provider, VMware Identity Manager is the Primary Identity Provider for any applications which it protects and the front-facing login portal which redirects to VMware Identity Manager is seen as the “3rd Party Identity Provider”.
Setting up a 3rd Party IdP in VMware Identity Manager:
In this procedure you will need two VMware Identity Manager tenants (either can be SaaS or On-Premises tenants). You will be setting up one VMware Identity Manager tenant as a 3rd Party Identity Provider within another VMware Identity Manager tenant which is acting as the Primary IdP.
- First let us get our descriptions clarified. When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other, we need to ensure we know which one we are talking about in the following instructions.
NOTE: Please reference Figure 2 and Figure 3 above when working through these procedures.- 3rd Party Identity Provider - This is the “3rd Party" Identity Manager tenant which the user is browsing to in order to login and view the app catalog and launch the apps. To note, when adding VMware Identity Manager to an existing IdP solution, this is how VMware recommends adding VMware Identity Manager to the solution since this allows incorporation with as little change as possible to the existing production environment while allowing incremental rollout to end users by having them authenticate to VMware Identity Manager to get all of their applications, desktops, mobile apps, and other services provided to them.
- Primary Identity Provider - This is the Identity Manager tenant (the IdP) which is providing authenticating and authorization to any of its application(s) and service(s) which it is protecting. VMware supports VMware Identity Manager in this configuration as well with other 3rd party IdP solutions.
- Since we are using two Identity Manager tenants, there are two sides to this configuration. One part is the work done on the Primary Identity Provider tenant and the other part is the work done on the 3rd Party Identity Provider tenant. The first part is configuring the 3rd Party Identity Provider tenant as a 3rd party IdP within the Primary Identity Provider Provider. This is done from the Primary Identity Manager tenant which provides the application protection in order for it to know who to accept authentication requests from. For example, Office 365 is protected by the Primary Identity Provider tenant…the 3rd Party Identity Provider tenant is where the user authenticates…and then the user clicks on an application called Office 365 which points the user to the Primary Identity Provider tenant and specifically to the Office 365 application for execution. Along with that redirection, the 3rd Party Identity Provider tenant provides a SAML Assertion which holds the appropriate claim to authenticate the user to the Primary Identity Provider and allow it to authorize the user to launch the protected application…in this case, Office 365.
- To get started, within the Primary Identity Provider Identity Manager tenant (i.e. The IdP which protects the applications), browse to the Admin Console from the Identity & Access Management > Manage > Identity Providers page and click on the Add Identity Provider button and select the Create Third Party IDP menu option.
- Fill in the necessary information in the New Identity Provider page.
- Identity Provider Name: A name for administrators to easily identify this new IdP.
- SAML Metadata: Provide the URL or XML of the 3rd Party IdP for trust. When using another Identity Manager tenant as the 3rd party IdP, to obtain the SAML Metadata, login to the administrative console on the 3rd Party Identity Provider Identity Manager tenant and browse to Catalog > Settings > SAML Metadata and right-click the Identity Provider (IdP) metadata link and copy the link address. The address will be as shown below, where <3RDIDPFQDN> is your 3rd Party Identity Provider Identity Manager tenant FQDN.
https://<3RDIDPFQDN>/SAAS/API/1.0/GET/metadata/idp.xml - Back in the Primary Identity Provider Identity Manager tenant (which protects the applications) where you are creating the new “3rd Party IdP”, paste or type the above URL into the SAML Metadata box and click the Process IdP Metadata button. This will auto-populate most settings.
- NOTE: The four Name ID Values which show up after processing the IdP metadata are the attributes which will be used between the two IdPs for mapping user accounts. Only one out of the four is needed (e.g. email) to match.
- NOTE: In this case, since we are using the same Active Directory between both Identity Manager tenants, we don't need to worry about account creation. Had we decided to use different Active Directory environments (such as two different companies linking their Identity Manager tenants together) or two internally different directories (e.g. Active Directory users with one Identity Manager tenant and Open LDAP or Local Directory Identity Manager users with the other Identity Manager tenant), we would only need to ensure one of the attributes maps (and that no other attributes match a completely different account) with a user account on both sides (i.e. If using email address as the mapping attribute, the user account in Identity Manager tenant using active directory has the same email address defined in the general tab of the A.D. Users and Computers account properties as the email address within the Local Identity Manager user account).
- NOTE: If not using the same A.D. domain for both Identity Manager tenants and instead manually creating a test user, only the mapped attribute(s) defined need to have matching values between the two Identity Manager tenants. Use the User and Groups tab in both Identity Manager tenants to compare your test account in each tenant to see if the mapped values match (for tenants using the same Active Directory domain, we know they will match so long as the test user account is synchronized to both Identity Manager tenants).
- NOTE: If some of the user attributes defined under the Name ID Value could potentially cross map to other user accounts, then remove them and stick with just the one or two attributes you know will be unique to each user (e.g. email or userPrincipalName).
- Name ID Policy is optional and not needed if doing Identity Manager to Identity Manager trusts.
- Just-In-Time User Provisioning is optional and would NOT be used if both IdPs are synchronized to the same Active Directory domain or if user account creation or synchronization is accomplished by some other fashion.
- If enabled, then an Identity Manager Directory name must be specified and it is recommended to provide a fully qualified domain (e.g. COMPANY.LOCAL, CUSTOMER.COM, etc.).
- Users: Select the user's directory/domain from the 3rd Party IdP which can authenticate to this Identity Manager tenant.
- Network: Select which network or network ranges the 3rd party IdP can be accessed from.
- Authentication Methods: Click the green “+” (plus) sign and add an Authentication Method. Give it a unique name and select urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.
- Single Sign-Out Configuration: This is optional. If enabled, provide a redirect URL for logout.
- Click the ADD button.
- Fill in the necessary information in the New Identity Provider page.
- The second part is to create an authentication policy with fallback authentication for automatic SSO of users coming from the 3rd Party Identity Provider Identity Manager tenant. This will allow the VMware Identity Manager tenant acting as the Primary Identity Provider to authenticate to the 3rd Party Identity Provider.
Within the Primary Identity Provider Identity Manager tenant (i.e. The one which protects the applications), this is done within the Admin Console from the Identity & Access Management > Manage > Policies page by clicking on the default_access_policy_set and editing each of the authentication methods to add in the new fallback authentication created in step 1.1.7 (NOTE: The unique name should now appear as an authentication method).- When opening the default_access_policy_set, you will see multiple authentication methods (by default you will see two - Identity Manager Client App and Web Browser).
- Edit all Policy Rules and add a new “Fallback Method” by clicking on the green fallback Method button.
NOTE: DO NOT ADD A SECONDARY AUTHENTICATION METHOD TO THE NEW FALLBACK METHOD! - From the new dropdown menu, select the newly defined method from the above procedure.
- Click the OK button.
- Edit all Policy Rules and add a new “Fallback Method” by clicking on the green fallback Method button.
- After all (or at least the desired) Policy Rules have been modified, click the SAVE button on the bottom of the default_access_policy_set page.
The Primary Identity Provider Identity Manager Manager tenant is now trusting the 3rd Party Identity Provider Identity Manager tenant and ready to authenticate and authorize users.
- When opening the default_access_policy_set, you will see multiple authentication methods (by default you will see two - Identity Manager Client App and Web Browser).
- The final part is to create a linked application from the 3rd Party Identity Provider Identity Manager tenant to the Primary Identity Provider Identity Manager tenant. In this case, this is done on the 3rd Party Identity Provider Identity Manager tenant which is providing the initial authentication for user accounts (not the same tenant as the one used above in steps 3 and 4).
NOTE: When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other Primary Identity Provider, we can link to one of the applications from the Primary Identity Manager tenant or we can link directly to the Primary Identity Provider tenant CONSOLE or Application Catalog, using that as the “application" which the Primary IdP is protecting (this is the app catalog console which a user would see when logging directly into the Primary IdP Identity Manager tenant).
Within the Service Provider Identity Manager tenant - where users will login to (i.e. NOT the same as the IdP Identity Manager tenant mentioned in the previous two major steps), this is done within the Admin Console from the Catalog > Manage > Application Catalog page by clicking on the Add Application button and selecting “…create a new one” from the Web Application menu.- When adding a new application in Identity Manager, a new window will appear requesting the application details. The only two details we need for this first window are a Name (the user will see this as well as any description added) and an Authentication Profile of SAML 2.0 POST Profile. It is recommended to add an icon which makes appropriate sense for end users to easily distinguish this application from others as well as a description but these are not absolutely required.
Here we will use the Identity Manager IdP tenant catalog as the “application”.- For Name, type "3rd Party Catalog”.
- For Description, type “Application Catalog of IdP Identity Manager Tenant <FQDN>” where FQDN is the actual FQDN of the IdP Identity Manager tenant.
- If you have a custom image you wish to use, click the Choose File button and browse to the image file and upload it.
- Ensure Authentication Profile is set to SAML 2.0 POST profile.
- Click the NEXT button.
- In RelayState type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN.
https://<IDPFQDN>/catalog-portal/ui
NOTE: You may choose to use any actual application protected by the Primary FQDN tenant. In that case, the RelayState URL pasted here is the Launch URL of the application from the Primary Identity Provider. For finding the Launch URL for non-SaaS/web based resources (e.g. Horizon, etc.), see further down. - Leave Proxy Count and Login Redirection URL blank. Leave all check boxes and other options in their default state.
- In the Auto-discovery (meta-data) URL, type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN. This is the Service Provider XML information of the 3rd party IdP as we are now addressing it as a Service Provider to the application we are creating.
https://<IDPFQDN>/SAAS/API/1.0/GET/metadata/sp.xml
NOTE: You can obtain this link from the Catalog > Settings > SAML Metadata page within the IdP Identity Manager Tenant Administrator Console. It is listed as Identity Provider (IdP) metadata within the SAML Metadata section of the page. - Click the SAVE button to process the IdP Metadata information. Doing so will automatically process the metadata information and move to the Entitlements tab.
- In Entitlements page, add in the Group or Individual entitlements. Assuming both Identity Manager tenants (both the SP and IdP) are synching the same set of users, simply entitle this app to ALL USERS. Set entitlement to AUTOMATIC (vs. User-Activated). Click SAVE on the Add Entitlements pop-up screen to get back to the main window.
- In the main window, ensure you click the DONE button above the Entitlements section.
- You should now be able to see the application in the catalog of the Service Provider Identity Manager Tenant as a regular user.
- Browse to the 3rd party Identity Provider (i.e. the VMware Identity Manager tenant which is in front of the Primary Identity Provider).
- This will be something like the following where <3RDIDPFQDN> is the FQDN of the first VMware Identity Manager tenant in Figure 2.
https://<3RDIDPFQDN>
- This will be something like the following where <3RDIDPFQDN> is the FQDN of the first VMware Identity Manager tenant in Figure 2.
- Login as a standard user who was entitled in Step 5.A.10 above (assuming the built in All Users group was used to entitle users, then any user will see the app).
- This user should have access to and see the newly created application from the previous section.
- Launch the application.
- This user should see the launch of the above application kick over in the browser to the Primary Party IdP VMware Identity Manager tenant.
- Assuming everything is properly configured above, the user should see the web app catalog of the Primary VMware Identity Manager tenant (or the application it is protecting if specified as such in step 5.A.6) launch from the VMware Identity Manager tenant acting as the 3rd Party Identity Provider!
- When adding a new application in Identity Manager, a new window will appear requesting the application details. The only two details we need for this first window are a Name (the user will see this as well as any description added) and an Authentication Profile of SAML 2.0 POST Profile. It is recommended to add an icon which makes appropriate sense for end users to easily distinguish this application from others as well as a description but these are not absolutely required.
Finding the Launch URL:
SaaS/Web Apps
Finding the Launch URL for SaaS/Web is fairly straight forward.
- Login as admin to your VMware Identity Manager tenant.
- Browse to Catalog (drop down arrow) > Web Apps and select the desired web app.
- Within the app details, you'll see the Launch URL shown.
- Click the COPY URL to copy the link.
Non-SaaS/Web Apps (e.g. Horizon, Citrix, ThinApp, etc.)
While it is fairly easy to find the Launch URL for SaaS/Web resources within the VMware Identity Manager admin console, doing so for non-web resources is a bit trickier as the full URL is not listed. It is, however, still pretty easy to do.
- Login as admin to your VMware Identity Manager tenant.
- Browse to Catalog (drop down arrow) > Web Apps and select any web app.
- Within the app details, you'll see the Launch URL shown.
- Click the COPY URL to copy the link.
- Paste this link within a text editor.
- Browse to Catalog (drop down arrow) > Virtual Apps and select the desired virtual app.
- Select the resource's Details on the left side menu.
- Within the app details, highlight and copy the External ID (SID) value.
- Within the text editor, modify the pasted URL by replacing the GUID at the end of the Web App Launch URL with the GUID from the Horizon Resource External ID (SID).
Resources:
- VMware Identity Manager Documentation - This is the latest online VMware Identity Manager documentation. Please note that you need to select the proper VMware Identity Manager version! You will also need to search the respective version documentation for the topic, "Configuring a Third-Party Identity Provider Instance to Authenticate Users".
- VMware Identity Manager Integration Documentation - This is all of the latest VMware Identity Manager integration docs published by VMware.
- VMware Workspace ONE integration with Third Party Identity Providers - This provides integration information between VMware Workspace ONE (VMware Identity Manager) and Third Party Identity Providers. Please feel free to send any feedback to respective content authors.
