Connecting ADFS with social logins
By “social logins” I mean logging in with Twitter, Facebook, Google, Windows Live etc.
Traditionally, you have been able to do this with some providers via ACS but that is tied to the classic Azure portal that is soon going to be deprecated. ACS itself is being retired on November 7, 2018. There are a number of migration strategies.
Azure AD B2C has some social providers and can be connected to ADFS but the connection is the wrong way i.e. B2C → ADFS.
There are a number of Identity as a Service providers out there that we could use e.g. Auth0, Okta, OptimalIDM etc. that all have social interfaces. These can be federated with ADFS.
I use Auth0 for a number of my customers and know my way around it so I’m going to use that as the basis for this post.
Auth0 has a range of social providers to select from.
NZ get a lots of Asian visitors and they like to use their own Chinese, Japanese and Korean social providers. You can see these above.
The flow is going to be:
Application → ADFS → Auth0 → Social provider
My test application uses WS-Federation, ADFS is going to connect to Auth0 via a custom SAML provider and Auth0 is going to use OpenID Connect / OAuth for the social connection.
As per the custom SAML link above, show the client’s advanced settings and then under the “Endpoints” tab, copy the metadata link.
This metadata needs to be imported into ADFS as a claims provider (CP).
Import the metadata and configure the claims rules as per this article.
On the Auth0 side, select and configure the social connections you want under “Connections / Social”. The buttons turn green for the ones you turn on.
Note. Do not use the developer keys. This won’t work. You need Production keys as described here.
Following the steps in the custom SAML link above, in the client set the callback URL:
In the Addons (SAML2 Web App), set the callback URL:
In the Connections, select the social applications you want to appear in the Lock screen. The Lock screen is the Auth0 login widget.
When you test the setup, your application will redirect to ADFS and you then select the Auth0 SAML CP connection from the ADFS Home Realm Discovery screen.
This will redirect to Auth0 and the Lock screen will be displayed. Notice the available social connections that were configured as above.
I used Windows Live to test.
You first get a consent screen:
Accept, authenticate on Windows Live as normal and the user is then redirected back down the chain through Auth0 and ADFS with the token and the application will then receive the configured claims.
Aside: ADFS is traditionally used for Enterprise scenarios e.g. federation with another corporate. However, there are times when you want “open”
applications e.g. applications controlled by an ADFS in the DMZ in its own domain. This handles external users. This domain has no access to the corporate intranet. In this case, it may be easier to simply let the users use existing social accounts rather than having some kind of custom on-boarding functionality.
All good!
