CODEWITHSUNDEEP
asp.netsaml-2.0okta
Jeff Anderson
Jeff Anderson

Reputation: 53

Implement SAML 2.0 as a service provider with ASP.NET 4.5+

I am having a hard time getting clear guidance from various sources on how to modify my existing ASP.NET application (non MVC if that matters - old web forms based with forms based authentication) to accept single sign on users via SAML. Specifically we are looking to connect to Okta. I have gotten OpenID Connect with Okta working, but our customers specifically want SAML through Okta. We would also like to support other Identity Providers in the future via SAML.

I have set up the app in Okta and gotten my x509 certificate and metadata, but am having a hard time proceeding from there. I have read a lot of conflicting information - some sources say SAML2 is built into .Net 4.5 and up, but others saying that it doesn't support the SAML2 protocol, and I have found no good examples for it that are not tightly bound to Azure and ADFS. I have looked at this repo, but apparently it does not support SHA256, which is what I have from Okta. Also the documentation on that library is very lacking. Most of my internet searches seem to find out of date or conflicting information of how to implement SSO via SAML on .Net.

Okta's own documentation is focused on OIDC or their own API, leaving the SAML implementation up to the integrator.

Can someone please point me to some current examples for ASP.Net SSO with SAML2? Preferably a web forms app rather than MVC.

Thank you in advance.

Upvotes: 1

Views: 5370

Answers (1)

codebrane
codebrane

Reputation: 4620

At the end of the day, all you have to do is provide a new SAML endpoint in your app and handle the stuff going in and out. All it does is detect if the user has a session at your app. If not, redirect them to their IdP with a SAMLRequest and wait for the browser to come back to your ACS (Attribute Consumer Service) endpoint with the SAMLResponse. If the attributes in the SAMLResponse are adequate, log the user into your app.

SAML doesn't know anything about logins, sessions or application stuff like that. It's just an XML bag of stuff that you use to manage logins etc.

The usual way of logging in with a username/password is something like:

https://yourapp.com/login

so SAML could be:

https://yourapp.com/sso

to support multiple identity providers, add an entityID param:

https://yourapp.com/sso?entityID=https://some.idp.com/shibboleth

you load the IdP's login page URL from its metadata, which you load using the entityID parameter. Send the browser to that URL to start the SAML process.

So the process is more or less:

  1. user accesses you /sso?entityID=blah endpoint
  2. load SAML metadata for entityID and get the SSO URL
  3. redirect browser to SSO URL with SAMLRequest encoded in form
  4. receive browser on your ACS endpoint with encoded SAMLResponse from IdP
  5. parse SAMLResponse to get SAML attributes and examine them for suitability
  6. log the user in

You'll need the SAML metadata for each IdP you intend to work with and they will need your app's SAML metadata as you are acting as an SP (Service Provider).

Upvotes: 3

Related Questions