This article is part 1 of 2 that will explain how using Microsoft Azure Active Directory (Azure AD), Oracle IDCS, and the Oracle App Gateway can be used together to seamlessly access a protected HTTP resource using your Microsoft desktop login without being prompted to enter your username or password.  As a bonus, the App Gateway can be configured to pass data downstream in HTTP headers to the protected web application.  In fact, what makes this solution even more interesting is it can help legacy applications that do support SSO trusted header authentication where normally the application does not support OAuth2, OpenID, or SAML. In this part 1 article, I cover an overview of how this solution works with some high-level details of the architecture.  In Part 2: Implementing Desktop SSO using Azure AD, IDCS, and App Gateway, I will detail step-by-step on how to implement this solution.

How the Integration Works?

This section covers a high-level explanation of how the integration works.  I would advise not skipping this section because there are a few moving parts to understand, understanding the integration can help in troubleshooting in the event there are problems.   

The following sequence diagram illustrate five actors:

1. Client AKA Edge Browser in this case,
2. Azure AD,
3. Identity Cloud Service (IDCS),
4. App Gateway,
5. protected HTTP resource(s)

Referring to the sequence diagram about, the Edge browser requests the HTTP resource, which is front ended by the App Gateway.  The App Gateway protects the HTTP resource, and acts like a reverse proxy to get to the HTTP resource.  In this case the App Gateway is configured to engage IDCS federation, and has been configured to use Azure AD as the Identity Provider.  When Azure AD is contacted, it not only completes the federation SAML request back to IDCS, but also magically takes care of the seamless desktop SSO leveraging the user’s credentials that they used to sign into their desktop.  The desktop credentials are extracted by Azure AD which allows it to know the user’s email address that is returned as the mapping attribute used in federating to IDCS. Note that the user account and the same email address also need to be created in IDCS, this is normal to accomplish federation.  Finally, IDCS uses some OAuth2 with the App Gateway to complete the SSO.  Ultimately the user goes right into the HTTP resource via the Edge browser without any need to enter credentials.  And as I pointed out earlier the App Gateway can additionally forward headers downstream to the target HTTP web application with information about the authenticated user such as username, email, etc. stored in IDCS or even hard coded headers to provide even legacy applications with SSO that support trusted header SSO.  

Optional Desktop SSO Points

Desktop SSO has been mentioned a few times, and I want to spend a little time talking about this because it is a key factor in making this solution work.  The desktop SSO is something taken care of by Microsoft's technology, and there are three supported solutions though it could be possible there are other alternatives.  The following options are possible, more details on these options can be found here Azure Active Directory Seamless Single Sign-On https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso. 

1. Password Hash
2. Pass-through Authentication
3. Active Directory Federation Services (ADFS)

In my example, the sequence diagram illustrates Microsoft seamless SSO using only Azure AD without any on-premises Active Directory AKA no hybrid approach; see the PAR box in the sequence diagram.  You will need to decide the best architecture that works for you.  A pure Azure AD solution, a hybrid architecture that combines Azure AD with an Active Directory domain hosted either on-premises or in the cloud, or something else.  Regardless of which option, this solution will work as long as 1) desktop SSO can be accomplished, 2) federation can be configured between IDCS and Azure AD, and 3) the App Gateway is leveraged.

App Gateway Architecture Options

When deploying the Oracle App Gateway, it can be designed with or without high availability.  What you decide is important because when the App Gateway is registered in IDCS you will need to provide a couple hostnames and ports that you will only know based on the App Gateway architecture you decide. The following diagram illustrates three common options, though there could be other combinations.

Review the options in the diagram above, decide which works best, and make note of the hostnames and ports highlighted in red for when you complete the App Gateway registration in IDCS once you implement the solution in part 2.  If you require designing for high availability see the official Oracle document https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/understand-app-gateway.html#GUID-1FE41A96-11CC-461E-85B9-9E163F134030 and reference section “Set Up High Availability”.

Summary

Hopefully this article provides a creative solution to provide seamless desktop SSO with any HTTP resource or even legacy applications that support trusted header SSO.  If this is interesting move on to Part 2: Implementing Desktop SSO using Azure AD, IDCS, and App Gateway, but be sure to fully understand how this solution works before continuing.