To be frank, this will not be a tiny bite but a more detailed walk-through of what happens under the hood when a guest authenticates using ClearPass Guest with a Social Login provider. In this particular case, I will cover what happens under the hood with Microsoft Azure AD using OAUTH 2.0. The same logic applies to other cloud providers. In a future post, I will cover how to configure this workflow. For now, let’s focus on how it works in details.
The Catalyst Behind this Post
Islam Zidan, one of the Aruba Experts in our partner community here in UAE, called me to discuss an interesting requirement from one of our customers. The customer wants his employees to access the Guest Network using their Azure Active Directory account instead of using the self-registration workflow. We were both sure it can be done using OAUTH or SAML but we didn’t want to waste time trying it at the customer site especially that access to the site is restricted these days. So, we decided to work jointly on testing the setup offline using both SAML and OAUTH. While testing this, we thought that others engineers might find it useful especially that it is not very well documented so we decided to write this post series explaining what happens under the hood!
The Authentication Workflow!
The below diagram shows the authentication workflow and the interactions between the various components. “Azure AD”, in the below diagram, is used as a “simplification” to cover multiple Azure services including Login, graph.windows.net..etc.
Step by Step View!
Steps 1/2: The user will connect to the guest network and will be redirected to the ClearPass Guest Portal page. The user will be placed in guest-logon role which will allow DHCP, DNS, https access to ClearPass, https access to Social Provider Login FQDNs, Captive portal redirection to ClearPass.
Step 3: The user will press login button and this will kick start the OAUTH workflow.
Steps 4/5: The browser will be redirected to the login page of the Cloud Provider (Microsoft in this case)
Step 6: The user will fill in the account details and the password and then sign in. In the post request, the client_id, redirection_url (callback) will be specified. The browser will be expecting a code as response_type.
Step 7: Azure will return an access code for the browser with a redirect back to the ClearPass guest page submitted in Step 6.
Step 8: The browser will be redirected back to the ClearPass Guest page. It will post back the code it obtained from Azure.
Steps 9/10: ClearPass will use the code, along with its client-id and secret to access Azure graph APIs. As per my understanding of OAUTH code workflow, ClearPass should exchange the code for an access token but I couldn’t any logs on ClearPass for this step. The logs that are available show ClearPass calling Azure APIs to collect the information about the user and his group memberships.
Step 11: ClearPass creates an endpoint entry and populates it with the fields it acquired from the Social Login Provider. The interesting field is the social_password which gets sent back to the controller to complete the radius authentication.
Step 12: ClearPass will instruct the controller to post-back back to controller so controller can do a radius authentication against Clearpass. The social_password is sent here.
Steps 13/14: Browser will post back to controller and controller will send radius request to ClearPass including the social password.
Steps 15/16: ClearPass validates the provided details against the Social Login Repository and returns a Radius Accept. The controller changes the role for the user and the user now has guest access.
This completes this workflow steps in details. Feel free to share your comments and feedback below. This next post explains the configuration in depth.
If you are interested to check other ClearPass Tiny Bites, click here.