Mfcttrf

I have a .net application that's wired up to my local ADFS server (connected to our corporate AD server) and everything is working fine. My question is, can my ADFS establish a trusted connection to additional SSO services out on the internet like Azure AD, AWS, Google login, Facebook, Twitter, OpenID, etc. so that my application could use claims from multiple trusted sources other than my Activate Directory?

It seems that chaining relying parties is indeed possible. This guy has written a series of posts about it, here's one. You can use ADFS as the "hub" for your app to auth against, and it will chain the request back to whichever service the user's identity actually lives in.

https://cloudidentityblog.com/2013/06/17/why-use-aad-as-idp-via-ad-fs-rp/

I haven't done this myself, so I'm not sure how much work this and what the pitfalls might be. I'm sure you could run into problems if a user lives in more than one IdP.

Don't forget, there's nothing preventing you from writing your .NET application to be able to take advantage of multiple SSO providers natively.

Yes, it can.

Each of these external IDP is added as a claims provider in ADFS and on the IDP side, ADFS is added as a Relying Party.

When you authenticate, ADFS will show a Home Realm Discovery screen that lists all the IDP.

You then choose which one you want to use.

I've done this. In our model, we have three sets of users:

1. Internal users authenticating via Active Directory (Kerberos or NTFS) against the local AD FS instance. In this set, the AD FS server runs as the IdP.




2. External users authenticating via Active Directory (Kerberos or NTFS) against their own AD FS instance and domain. In this set, the AD FS Server has a Claims Provider Trust configured to the issuing AD FS server. Our AD FS server operates as an SP-STS by transforming and validating claims issued elsewhere, and reissuing a trusted token to our application. The IdP is the other domain's AD FS server, where our AD FS server is configured as a relying party.




3. External users without corporate login. These users authenticate to small .Net STS which is configured as a Claims Provider Trust on our AD FS server. (We did also consider - and it was technically straightforward - to use Azure Active Directory B2C for this role, but other concerns prevented it.)

Tokens are issued as:

To make it transparent for our customers, we use IP ranges to detect (via nginx) and redirect to the appropriate corporate AD FS – and otherwise rely upon the standard AD FS HRD page.