In my previous post I showed to you how easy it is to configure Azure AD to act as Identity Provider to Relying Party applications via AD FS. There were questions about ability to configure applications directly with AAD. If it is possible and if it is, then why would anyone want to use AD FS in the middle. The answer is yes, of course it is possible to configure applications to work directly with AAD, in fact most of the AAD online documentation provides examples on how to do that. The second part of this, ok, since we can configure apps to work directly with AAD, why put AD FS in the middle? The simple fact is that not all applications will be configured directly with AAD, and there are a lot of applications that are already configured in some type of federated topology. Lets take a look at the following diagram, here we have hub/spoke environment with a few Identity Providers, central hub and a few applications. Users at each IdP are able to use applications via the central hub. The fact of the matter here is that those IdPs can be any compatible Security Token Service and those IdPs do not care how other IdP are configured. As long as IdP-HUB RP relationship is working, users will be able to access target applications.
Image may be NSFW.
Clik here to view.
This design accommodates requirement to add any number of new Identity Providers and get them to access target applications. So if we have a new customer who uses AAD as their primary user directory and they need to get access to some existing apps, the primary solution would be to configure AAD as another IdP against our hub RP AD FS. Now users in AAD will be able to gain access to the applications. Hub RP claim rules can even transform incoming assertions from one claim type to another, to whatever is required by the target application.
Image may be NSFW.
Clik here to view.
Thanks for stopping by!
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
