I've blogged about this before viz:
SAML : SAML connectivity / toolkit
and the links inside that post.
The general problem is that you have a .NET application and you have a use case that requires you to authenticate with a SAML IDP.
There are two general approaches:
- Add a SAML client side stack
- Use something like ADFS as a bridge i.e. app --> WS Fed --> ADFS --> SAML --> IDP.
Note that when I talk about SAML I refer to SAML-P (the protocol) as opposed to SAML (the token).
But then I came across
Auth0.
This has an interesting approach. Instead of having many applications taking to many Identity repositories (perhaps many-to-many - the spider's web scenario) , they have Identity aaS and each component has one connection into the circle. You then hook all the connections up with internal plumbing.
Internally, everything uses OpenID Connect. They also have something similar to the FIM metaverse concept i.e. a standard profile where they keep the essential information and that links all the different user identities together. So one profile holds that user's information for their Facebook, Twitter, ASP.NET Identity etc logins.
So how does this help the problem?
Auth0 provide a login widget (that they call Lock) that can be easily referenced by Javascript, code etc. This widget uses OpenID connect. The .NET applications uses this to get into the circle and then you configure another connection out of the circle which uses SAML to talk to the IDP. You then hook the two connections together.
Conceptually:
App --> OpenID Connect --> Auth0 --> SAML --> SAML IDP.
Now ADFS supports SAML-P so lets hook this all up as an exercise.
Following assumes you have an Auth0 developer account - which is free.
Auth0 has a number of samples on
Github.
You can search for a MVC sample but for this particular investigation, I was interested in what Microsoft call a native device i.e. non-browser based. Mobile is a good example but so is command line or Windows Forms or WPF. There is a Forms / WPF example
here.
In the example, where it says:
var auth0 = new Auth0Client(
"{YOUR_AUTH0_DOMAIN}",
"{YOUR_CLIENT_ID}");
You get these by creating a new App / API in the dashboard, Select:
Native Mobile App and then WPF / WinForms as the SDK Skip the Backend Platform.
You then get a tutorial. One neat thing is that if you log into the dashboard beforehand, all the tutorials are customised for your Auth0 domain and settings.The tutorial contains the settings you need, otherwise they are in the application settings for your application in the dashboard.
If you were looking for ASP.NET MVC, note that the only difference to the Forms / WPF approach is how you hook up to the widget i.e. you would use Javascript instead of C#. All the plumbing / configuration as below is identical.
Let's hook up the SAML.
Connections / Enterprise / SAML-P Identity Provider / Create New
You can give the connection any name you want and the URL's are the standard:
https://xxx/adfs/ls/
We'll ignore signing the request for now.
Now for the certificate:
ADFS wizard / Service / Certificates / right-click on Token-Signing / View certificate / Details tab / Copy to file
Choose Base 64 Encoded X509 (.CER)
Save this somewhere and then click "Upload Certificate" as above and upload it to Auth0.
Auth0 use a domain matching way to handle the typical Home Realm Discovery. In the "Email Domains" box above, enter a domain. This does not have to be a valid domain - just something that you can match on e.g. mysaml.co.nz. Yeah - I'm not wild about this either!
Now for the ADFS side - click on your new connection and then click the pencil (Setup). This shows the Auth0 endpoints or you can use the metadata link.
I just configured ADFS manually because I've done this so many times.
ADFS wizard / Trust Relationships / Relying Party Trusts / Add Relying Party Trust.
Going through the wizard:
Start / Enter data about the relying party manually / Next / Type any name you want / Next / AD FS profile / Next / ignore encryption so Next / Check enable support for SAML protocol- enter URL as below / Next / enter identifier as below / Add / Next / ignore MFA so Next / Permit all users / Next / Next / Close
Again, note that the strings above will reflect your Auth0 tenant and connection name.
Didn't bother with a signature because we are not signing the AuthnRequest. Note that these reflect the name I chose i.e. ADFS-SAML. You will use your name as reflected in the Auth0 endpoints.
Now edit the claims rules so they look like:
Now if you go back to your SAML connection in the Auth0 dashboard, you can click on the Try icon (the arrowhead) and if all goes well, it will come up with "It Works!".
OK - so fire up the WPF application.
Enter e.g. joeb@mysaml.co.nz. This matched the Auth0 configuration so the Lock widget brings up the "Log in to mysaml.co.nz"
(BTW, if you are wondering about the social icons in the widget, this is configured in your application under Connections).
Click this and you will be redirected to ADFS where you can login as usual. Because you configured this to use SAML you now have a .NET application using SAML to authenticate. Neat!
Don't believe me? If you went with a standard MVC application and use FireFox, download the
SAML tracer and run it (under Tools). Clear all your cookies, login in again and you'll see some of the entries in the trace have an orange SAML button.
Update: I wrote this up:
SAML : ASP.NET MVC application talking to SAML IDP
(BTW: I don't work for Auth0).
Enjoy!
