I have a SaaS web application that caters to multiple education institutions. All clients are hosted in the same application/database. The application is currently written in C# for ASP.Net 4 Web Forms.
Currently my application uses a local/native database for user authentication/authorization.
Our clients are asking us to support single-sign-on where the client is the authentication provider and my application the consumer.
The problem is that the clients are asking for SSO via different protocols/mechanisms like Shibboleth and OpenID Connect. This means I need-to/should create a solution that works with all of these or that is at least extensible.
I came across Thinktecture's IdentityServer, which I think can abstract the various SSO mechanisms used by my clients and return to my app a claims based identity token that my app understands.
I'm struggling a lot with this concept though. Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user? How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)? Does the IdentityServer need to validate the existence of the user in my app's local/native database? Can the IdentityServer handle both SSO and local logins?
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server). But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it. ADFS may provide a similar solution, but most examples out there speak to ADFS and Azure.
Lastly, I'm assuming that I'll still maintain local/native authorization data about each user as the 3rd party authentication provider can't possibly know the specific authorization needs of my application.
Any thoughts or suggestions out there?
Here's the SSO process boiled down to four steps: The user arrives on the website or app they want to use. The site sends the user to a central SSO login tool, and the user enters their credentials. The SSO domain authenticates the credentials, validates the user, and generates a token.
Single Sign-On (SSO) is a protocol used to authenticate and authorize users to multiple applications while using a single set of credentials. SSO is very convenient for users because they don't need to memorize multiple passwords or repeatedly perform logins.
Single sign-on (SSO) is a technology which combines several different application login screens into one. With SSO, a user only has to enter their login credentials (username, password, etc.) one time on a single page to access all of their SaaS applications.
SSO offers seamless authentication with one credential across multiple connected platforms or systems. On the other hand, social login allows users to access services by authenticating themselves using their social account credentials.
Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user?
Basically YES. But it depends on how you set it up. Your page could call Authentication provider of the client if you have only one client or one authentication provider. Or you could set up your local IdentityServer (more extensible IMHO) and configure authentication provider of your client as another IdP (identity provider).
How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)?
If you go with the second option then your app will redirect to IdentityServer and based on home realm it will be automatically redirected to IdP. If no home realm is specified by your application then IdentityServer will show all configured IdPs and user chooses what IdP to authenticate at.
Does the IdentityServer need to validate the existence of the user in my app's local/native database?
It depends on you. If you wish to verify the existence of the user in your local database then you may do so by extending IdentityServer.
Can the IdentityServer handle both SSO and local logins?
Yes, it can.
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server).
You can always use IdentityServer and integrate it in your local application. Or you can use Shiboleth as your local authentication provider. Both are implementing standards like WS-Federation, WS-Trust or OpenId and both are open source so you can extend/modify it to your liking.
But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it.
I can't really say how much documentation is there. But if you wish, NDC Oslo 2014 will feature 2 days of Pre-Conference Workshops where Dominick Baier and Brock Allen (authors of IdentityServer) will teach you everything you want to know.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With