Workspace ONE Access integration
this blog is the fifth part of the tutorial.
Part 3: ServiceNow integration with PingFederate
Part 4: Office 365 integration with PingFederate
Part 5: PingFederate integration with Workspace ONE Access
Introduction
All right, time to start working on our main objective: the integration of Workspace ONE Access and PingFederate.
Quick recap on the desired outcome:
- Workspace ONE UEM managed Android devices should authenticate against Workspace ONE Access using mobile SSO.
- Unmanaged Android devices, as well as all other platforms should continue to use PingFederate for authentication using username password.
It’s obviously possible that you need a different flow, but in the end all you’d need to modify (on PingFederate) is the PingFederate policy that decides how to route the authentication requests.
This tutorial takes you through the following steps:
- Adding Workspace ONE Access as an IdP in PingFederate
- Configuring Ping as an application source in Workspace ONE Access
- Building selectors in PingFederate
- Creating Policies and policy contracts
- Adding Workspace ONE Access as a Service Provider in PingFederate
- Adding PingFederate as an IdP in Workspace ONE Access
We’ve got 6 million screens to process, so go grab a coffee and make yourself comfortable!
Note: I may have omitted certain screens here and there to reduce the length of this article, that means no changes were required!
Assumptions
At this point, you should have the following up and running:
- Workspace ONE UEM and Access, integrated with Active Directory
- SaaS apps like Office 365 or ServiceNow federated with PingFederate with user objects synced from Active Directory.
- PingFederate installed and integrated with Active Directory for username and password authentication.
- Android Mobile SSO configured in Workspace ONE UEM and Access.
Adding Workspace ONE Access as an IdP in PingFederate
To be able to redirect Android devices to Workspace ONE Access for authentication, we need to add Workspace ONE Access as an IdP in PingFederate.
First step of the process is to export the IdP metadata from you Workspace ONE Access admin portal. Navigate to Resources > Web Apps and click Settings:
Next, open the SAML Metadata tab and save the IdP metadata:
Back in the PingFederate admin console, navigate to Authentication > Integration > IdP Connections and select Create Connection:
On the Connection Type screen, select Browser SSO profiles. Leave the protocol to SAML 2.0:
Click next until you reach the Import Metadata screen, select the metadata file exported in the previous step and click Next:
On the General Info screen, I modified the Connection Name, but that’s optional:
On the Browser SSO screen, select Configure Browser SSO.
On the SAML profiles screen, select both IDP-Initiated SSO and SP-initiated SSO (we want our users to be able to launch a web app from the Workspace ONE app catalog (IdP-initiated) as well as by directly navigating to the Service Provider (SP-initiated):
On the User Session creation screen, select Configure User-Session creation:
Click Next on the Identity Mapping and Attribute Contract screens.
On the Target Session Mapping tab, Select Map New Authentication Policy:
On the Authentication Policy Contract screen, select Manage Policy Contracts:
Select Create new Contract:
Provide a name for the contract, e.g. Workspace ONE Access Policy Contract:
Click Next on the Contract Attributes screen:
Click Save on the Summary tab:
Click Done on the Policy Contracts tab:
When back on the Authentication Policy Contract screen, select your newly created contract and click Next:
We’ll keep it simple in this lab setup, so select the option to use only the attributes in the SSO assertion:
map the subject as follows:
Skip the Issuance criteria screen and click Done on the Policy Mapping Summary tab:
click Done on the User-Session Creation Summary tab:
On the protocol Settings tab, select Configure Protocol Settings:
We only need Redirect and Post:
Skip the overrides tab and verify the Signature Policy settings:
We’ll not be encrypting the SAML messages for this setup:
Click Done on the Protocol Settings Summary tab:
On the Credentials tab, select configure credentials. Then select your signing certificate on the Digital Signature Settings screen:
Review the settings and click Done on the Summary tab:
Verify the IdP Connection is enabled and click Save:
Configuring Ping as an application source in Workspace ONE Access
First, we’ll need to export the metadata from PingFederate:
Select your Signing certificate again:
and click export:
Head over to the Workspace ONE Access admin portal and navigate to Settings > Web Apps. Click Settings:
On the Application Sources tab, select Ping:
Copy content of Ping metadata and press next, next, Save so Access processes the metadata file. Then come back to modify the username value.
Note: I selected username as my environment is very basic, but it might make sense to use a different attribute like UPN in your environment.
Reconfigure ServiceNow and Office 365 to use the Workspace ONE Access policy
In the previous blog posts, we configured both ServiceNow and Office 365 to use the local HTML form adapter as means of authentication. Now that we have integrated Workspace ONE Access, we can start sending these authentication request over to Access. Once we confirmed that the integration with Workspace ONE Access is working as expected, we can start building a more granular authentication policy that matches our use case.
In the PingFederate admin console, navigate to Applications > Integration > SP Connections and click on your ServiceNow app.
Select the Browser SSO tab and click Configure Browser SSO
Next, click on Configure Assertion Creation:
Open the Authentication Source Mapping tab and select Map New Authentication Policy:
On the Authentication Policy Contract tab, select your Workspace ONE Access policy contract and click Next:
If you recall from the third post in the series, ServiceNow is expecting the username to be passed in the SAML assertion. This matches what we are sending in the SAML response generated by Workspace ONE Access, so no need to search for additional attributes here.
Match the SAML subject to the subject in the Authentication Policy Contract:
Skip the Assertion Creation screen and select Done (not Save) on the Summary screen:
Delete the HTML Form Adapter and press save.
Open an incognito browser windows and navigate to your ServiceNow instance. You should now be redirected to Workspace ONE Access for authentication.
Let’s repeat the for Office 365. This deviates from the ServiceNow setup in the fact that we need to look up additional attributes. Office 365 is expecting the immutable ID as subject and userPrincipalName as additional attribute in the SAML response, so we need to query Active Directory instead of just relying on the SAML assertion generated by Workspace ONE Access.
Open the Office 365 app in Pingfederate and navigate to the Browser SSO tab, select Configure Browser SSO:
Select Configure Assertion Creation on the Assertion Creation tab:
Open the Authentication Source Mapping tab and select Map New Authentication Policy:
On the Authentication Policy Contract tab, select your Workspace ONE Access policy contract and click Next:
On the Mapping Method, we’ll need to select another option this time that allows us to retrieve the required attributes:
On the Attribute Sources & User Lookup tab, select Add attribute Source:
We’ll be querying Active Directory for the additional attributes, so select Active Directory on the Data Store tab:
On the LDAP Directory Search tab, enter the Base DN and add the objectGUID and userPrincipalName attributes:
Verify that you are Bae64 encoding the objectGUID attribute:
We’ll query Active Directory using the subject of the SAML response generated by Workspace ONE Access (sAMAccountName=${subject})
Next, we need to fulfil the requirements to authenticate to Office 365 with SAML by sending the attributes found in AD:
- IDPEmail – LDAP – userPrincipalName
- SAML_NAME_Format – Text – urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- SAML_Subject – LDAP – objectGUID
On the Summary screen, click Done. On the Failsafe Attribute Source, select to abort the SSO transaction:
Click Done again on the Summary screen. Next, delete the HTML Form adapter and click save:
You can now launch an incognito browser window and test the authentication flow using Workspace ONE Access!
Building Selectors in PingFederate
At this point, we’re sending all authentication requests for ServiceNow and Office 365 to Workspace ONE Access. That’s not exactly what we are looking for, given our use case (only Android devices should be sent to Access).
That’s where Policies come into the picture. These policies decide on the fly how to deal with incoming authentication requests. For our use case, we’ll be creating 2 selectors to build our policy:
- Mobile client selector: looks at the user-agent string to filter the operating system used to send the authentication request
- Application Selector: filters on applications
To build these selectors, navigate to Authentication > Policies > Selectors and click Create New Instance:
Next, select a name and instance ID and set the type to HTTP Header Authentication Selector:
In the Match expression field, enter *Android*. In the Header Name field, enter User-Agent:
Note: You can add additional platforms here if needed for your specific use case (e.g. *Iphone* or *IPad*).
Click Next and Save on the Summary tab.
Next, select Create New Instance again to build the application selector:
For my use case, I want to redirect Android authentication requests for both Office 365 and ServiceNow to Workspace ONE Access, so I’ll add both these apps in this selector. On the Type screen, give a name for your selector (e.g. ApplicationSelector for ServiceNow and o365), provide an Instance ID and set the type to Connection Set Authentication Selector:
On the Authentication Selector screen, select the apps you want the policy to forward to Workspace ONE Access. Then click Next and Save:
Building PingFederate Authentication Policies
We now have everything ready to build the actual policy. So navigate to Authentication > Policies > Policies. Select both IDP authentication policies and SP Authentication Policies and click Add policy:
Enter a name and description for you policy:
We’ll build a policy as follows:
Check if the app is ServiceNow or Office 365
- If no, present the user the standard HTML form adapter to enter his AD username and password.
- If yes, check if it’s an Android device.
- If not Android, present the user the standard HTML form adapter to enter his AD username and password.
- If it is an Android device, forward the device to workspace ONE Access.
So the first step of the policy, is to use our Application Selector:
If the application doesn’t match, we just show the default HTML Form adapter:
If authentication on the HTML Form adapter fails, we deny access to the application. If the authentication was successful, the policy contract linked to the app is fulfilled:
If the incoming request does match the applications in our Application Selector, we’ll check if it’s an Android device:
In case it’s not an Android device, we’ll again show the default HTML Form adapter:
If it is indeed an Android device, we’ll be forwarding the request to our external IdP (Access):
If authentication on Workspace ONE Access failed, we deny access. If it was successful, we fulfil the policy contract:
Before we can save the policy, we need to make a couple of changes:
For each of the HTML Form Adapters (2x in this example) in the policy, select options:
Set source to Context and select Requested User as attribute:
Repeat that same process for the Workspace ONE Access IdP Connection:
For the Policy contract Mappings that need to be fulfilled when HTML Form Adapter is used (2x in my example), select Contract Mapping:
Click Next on the Attribute Sources & User Lookup tab:
On the Contract fulfillment tab, set Source to Adapter and the value to username. Then click Next, Next, Done
For the Policy contract Mappings that need to be fulfilled when Workspace ONE Access IdP is used (1x in my example), select Contract Mapping.
On the Contract Fullfillment tab, select Source = IdP Connection (Workspace ONE Access) and set the value to SAML_Subject:
Click Next, Next and Done.
Back on the policy screen, click Done again. Then press Save on the policies tab.
You can now test if your policy is indeed working correctly. Android clients should now be redirected to Workspace ONE Access, all other platforms should see the PingFederate HTML Form Adapter.
If you don’t have an Android device at hand, use a browser plugin like the excellent user-agent switcher plugin available in Firefox:
Adding Ping apps to Workspace ONE Access
If you are leveraging the Workspace ONE Access app catalog on your mobile devices, you may want to add the Ping apps to your app catalog.
To do so, open the Workspace ONE Access admin console and navigate to Resources, Web apps and select New.
Provide a name and upload an icon. On the configuration page, select PING Application Source as authentication type.
As target URL, provide the URL to launch the application. This should match the Base URL value of your SP connection in PingFederate:
Assign the apps to the proper target audience and authentication policy and that’s it!
Configure Redirect Validation on PingFederate
At this point, when you start an IdP-initiated authentication, by clicking the icon of ServiceNow in the Workspace ONE app catalog,, you would bump into this error:
To get rid this error, we need to configure Target URL Mapping. Open the PingFederate admin console and navigate to Applications > Integration > Target URL Mapping and add the URLs for your apps. These should match the Base URL you see on the Summary screen of your SP Connection:
Adding PingFederate as an IdP to Workspace ONE Access
Remember that we are now sending all Android devices to Workspace ONE Access if they’re trying to access ServiceNow or Office 365. If these devices are managed, they will use mobile SSO and seamlessly access the target applications.
However, unmanaged devices – like BYOD devices – may not be expecting to see a Workspace ONE Access screen to provide their credentials. If you want these unmanaged devices to authenticate on PingFederate like they have always been doing, we’ll need to send them back to where they came from.
To achieve this last goal of the tutorial, we’ll be doing the following:
- Add Workspace ONE Access as a Service Provider in PingFederate
- Add PingFederate as an external IdP in Workspace ONE Access
- Modify the Workspace ONE Access policy to use PingFederate in case mobile SSO fails
First, in the Workspace ONE Access admin portal, navigate to Resources, Web apps and click settings. Open the SAML metadata tab to download the SP metadata:
Next, head back to the PingFederate admin console > Applications > Integration > SP Connections and select Create Connection.
On the Connection Template section select Do not use a template:
On the Connection Type screen, select Browser SSO profiles:
On the Connection Options screen, click Next:
On the next screen, import the Workspace ONE Access SP metadata file obtained earlier:
Skip the Metadata summary screen and (optionally) modify the Connection name on the General Info screen:
On the Browser SSO screen, select Configure Browser SSO:
This time, we only care about the SP initiated flow:
Continue to the Assertion Creation screen and select Configure Assertion Creation:
Skip the Identity Mapping and Attribute Contract tabs. On the Authentication Source mapping tab, select Map New Adapter Instance:
On the adapter Instance screen, select your HTML form adapter:
Leave the default value on the Mapping Method screen:
On the Attribute Contract Fulfillment screen, select Source = Adapter and Value = username:
Skip the Issuance criteria screen as always and click Done on the Summary screens for both the IdP Adapter Mapping and Assertion Creation screens.
Move on to the Protocol Settings screen, click Configure Protocol Settings:
We only need POST, so any other binding can be removed:
On the Allowable SAML Bindings tab, only select POST and Redirect:
On the Signature Policy tab, Select Always Sign Assertion:
Click next on the Encryption policy screen and Done on the Summary tabs for Protocol Settings and Browser SSO.
On the Credentials tab, select Configure Credentials:
Select your Signing Certificate and click Done:
On the Activation & Summary tab, review your configuration and active the app.
Head back to the SP Connection tab and export the metadata:
Select your Signing certificate on the Metadata Signing tab and click Next:
On the export and Summary tab, click the Export button:
Head back to the Workspace ONE Access portal > Integrations > Identity Providers and create a new IdP. Provide a name and paste the content of the metadata exported from PingFederate, then click Process IdP metadata:
Select the users that are allowed to use this IdP and select the proper network range(s)
In the Authentication Methods section, add an authentication method using PasswordProtectedTransport Context:
Click Save and navigate to Resources > Policies. Modify your policy or policies to use the newly created PingFederate authentication method in case mobile SSO fails (which will fail in case of an unmanaged Android device):
Conclusion
As this was the first time I came in touch with the Ping platform, I was shocked by the amount of options available and needed some time to get used to all the new terminology. Next to that I often felt lost when I was clicking through the large number of screens to click through to set up a simple SAML federation. But now I’m starting to see the flexibility it offers and combined with mobile SSO offered by Workspace ONE Access, it offers a superb user experience.