hi my name is Peter Bjork and in this video I'll walk you through how to configure a third party
identity provider or an IdP in Workspace ONE Access Workspace ONE Access supports a
wide range of authentication methods inbound as well as outbound from Access this offers
great flexibility for the IT admins but also a great user experience for your end users in this
video I'll focus on the inbound SAML and OpenID Connect or OIDC support throughout this video I
will use SAML and OpenID Connect terminology and there are some settings I will not go deeper into
at the end of this video I will show you links to videos explaining SAML and OpenID
Connect as well as videos that go deeper into certain features that I'm skipping in this video
you can also find links to these videos clicking on the more menu if you are watching this video on
techzone.vmware.com Workspace ONE Access is VMware's identity provider you can federate
applications to access offering single sign-on access to applications when federating an
application to access the application is called a service provider when using SAML
and referred to as a relying party when using OpenID Connect but many enterprises already have
a central source of truth for user authentication and when implementing Workspace ONE Access
they want to continue using existing methods of authentication then you add the existing solution
for example Microsoft ADFS Ping or Okta as a third party IdP into Access then Access is in this
trust relationship the SP or relying party and the third party is the IdP or claims provider
when a user requests access the user is redirected to the third party IdP
and performs the authentication there and once successfully authenticated
the user is allowed access into Workspace ONE Access and now the user can launch any other
federated applications without any additional prompts for authentication when adding a third
party identity provider you start by choosing to create either a SAML or an OpenID Connect IdP
then you configure the integration and name the methods of authentication this name will be the
names of the authentication method you can later refer to within your access policies but it's
much easier to show you in real life in my demo environment i'm using two different Workspace
ONE Access tenants the green one is called aw the peb and will act as my IdP my service provider or
relying party is named aw the peb2 the first part of my demo will be creating a SAML third party IdP
to help me establish the SAML trust or federation I will take the SAML IdP metadata from aw the peb
and import it into aw the pep2 and then I'll grab the sp metadata from aw the peb 2 and add
it to my IdP instance the green aw the peb then I'll do the same thing but using OpenID Connect
and to help me configure the OIDC relationship I will make use of the OpenID configuration url
I will start on my identity provider aw the peb I will create a new application which is my
aw the peb 2 tenant I name the new application aw the pep2 SAML and add a nice icon to it
the integration type is saml2.0 by default so I do not need to change that but I need these
sp metadata so I go to my aw the pep2 tenant and copy the link to its sp metadata
when adding integration using a metadata file you must step through the wizard and save
for the metadata to be processed next I edit the application and as you can see all settings from
the metadata has been added I will change the username value to use email instead of username
in both my Access tenants I have user objects already created and for the federation the email
address is the attribute that is common across my two systems and therefore the best attribute to
use as my user identifier I'll leave the username format as unspecified I could have changed it to
let's say email but it doesn't really matter much as long as I remember to specify the same
settings on my sp I'll save my changes and assign this new application to my users
now my IdP knows about my aw the pep2 tenant
next I need to establish trust in aw the pep2 to my IdP for that I need the IdP
metadata
I create a new SAML IdP and name it aw the peb saml so I can easily identify it
and then I paste the IdP metadata as you can see my IdP supports many different name id
but in my case I will only use email with the name id format unspecified all the others I can delete
in this case I'm using name id as the user identifier if you want to make use of attributes
as the user identifier instead you can watch the video i created called VMware Identity Manager
improved SAML attribute support a link to it can be found at the end of this video or under
the more menu next we have some more settings like the just in time or JIT user provisioning
I've also created a video explaining this setting more in depth
and that video is called VMware Workspace ONE Access local and just in time users
other settings are which user directory and network segments can this third party IdP service
in my case it is for the users in my pinata.local directory and I will allow it to be used from any
network next is the authentication methods which I'm afraid is a little complicated
so let me try to explain it a little more in depth
in SAML one of the information passed in the SAML assertion is the method of authentication used
this is handy since this means an SP that trusts an IdP might not accept all methods
of authentication from that IdP or could restrict access to its data based on the
level of authentication used and when you create the third party IdP within Workspace ONE Access
it is you who name the authentication methods this or these names are later showing up in your
access policy when it comes to SAML as already mentioned the method of authentication is sent
in the assertion this is called the SAML context so as an admin you name a method of authentication
and map it to a specific SAML context this way you know what authentication method name
maps to which SAML context so far so good now comes the tricky part
all IdPs don't send specific sample context but one that does is Microsoft ADFS and Azure AD
and Workspace ONE Access validates its access rules from top to bottom and when
the first match is found it executes the rule by taking the first authentication method listed
and access will specify the SAML context in its request for authentication message
sent to the third party IdP so with that as the backdrop if my Microsoft ADFS is configured
to support multiple authentication methods it will send a different SAML context for each one
and if access sends a specific SAML context in its request that method of authentication might
fail on ADFS for that particular user so instead of limiting ourselves to one specific saml context
when integrating with Microsoft IdPs we can create a method of authentication using the
unspecified sample context this tells ADFS any method of authentication is acceptable to use
and since the sample context in return from ADFS will reflect the real method used
we must list these saml context variations as fallback methods of authentication in Access
sounds complicated let's take it one step at a time
user hits access the conditional access is evaluated and the first match has the
authentication method name aw the peb underscore unspecified as its first authentication method
access generates a request for an authentication message specifying saml context unspecified which
is sent to let's say Microsoft ADFS the user is prompted for authentication and in this case it
is username and password which translate to the password protected transport saml context
Microsoft ADFS generates the saml assertion containing the saml context of password protected
transport and sends it over to Workspace ONE Access Access validates the assertion looking
at the sample context and finds a match in the authentication method called aw the pair
of underscore pw and the user is allowed access hopefully that explained it so now even though I'm
not integrating with the Microsoft IdP I'll create these three types of authentication methods in
Access
now my third party IdP is created next I simply have to reference it in my access
policies and just to demonstrate how to do it using all three methods of
authentication I add them all to my policy rule
let's give it a try I launch a new private window of my browser and type in the FQDN of my aw the
peb2 tenant I'm immediately redirected to my third party IdP the green aw the peb
I authenticate and get redirected as an authenticated user into aw the pep2 so SAML
integration seems to work next let's do the same thing but using the OpenID Connect protocol I'll
start on my relying party the aw the pep2 tenant I create a new OpenID Connect IdP or provider
similar to the metadata file in SAML
OpenID Connect has the OpenID configuration which helps you configure the integration
if not available you will have to ask the other side for all the required URLs
since OpenID connect is based on OAuth 2.0 we will have to specify an OAuth client id and secret this
client id and secret is typically something you get from your OpenID connect provider to identify
the user I will make use of the email attribute then you have the same JIT user creation setting
and user directory and network range settings as we saw when creating a SAML third party IdP
and lastly you name the method of authentication but with OpenID connect you don't have the same
concept as in SAML with the saml context but this name is what will show up in the access policies
I copy the redirect URL so I can create the representation of aw the pep2 tenant in my IdP
but first I change my access policies to make use of the new OpenID connect integrated method of
authentication
on my OpenID connect provider I create a new application and
choose the authentication type OpenID Connect
I specify my target URL which is basically my tenant FQDN and then the redirect URL I copied
earlier I specify the OAuth 2.0 client id and secret used to identify my aw the pep2 tenant
and this will create the OAuth 2.0 client locally on aw the peb
next I must modify the scope of the OAuth 2.0 client just created I do that in catalog
settings remote app access and here you can see my OAuth 2.0 client I add the profile and email
scope to it this way it can retrieve the user's email address which I specified as the attribute
to be used to identify users and finally let's test this now
I start by going to aw the peb2 and gets redirected to the green aw the peb
I log in and I'm allowed access
as mentioned previously I've created a couple videos complementing this one first
I have the SAML 2.0 overview video explaining everything you as an id admin needs to know
about SAML the OAuth 2.0 and OpenID connect video does the same thing for those two protocols
and then we have the workspace one specific videos going into depth of using SAML attributes
instead of name id as the user identifier and the use of just-in-time user creation
I hope you found this video useful and as always for more technical content please visit
techzone.vmware.com