0

So we have an .NEt Owin / Katana Oauth Webapi2 Bearer server which sits on top of a SQL Server Database using .Net Identity and Entity Framework . Users can use Oauth to login from 3rd party apps and such, most of which are other .net MVC apps. Life is good.

Now we find the need to support All the things. Clients want to use SAML2, OpenID, Oauth, JWT's and more to login our users. What I'm finding is all the information needed to connect to an identity provider but not how to actually BE an identity provider. We are considering a move to a more enterprise grade solution like Active Directory, OpenAM, Shibboleth etc... but before pulling the trigger on something like that I am trying to get more info.

I looked into Azure ADFS in the cloud but like other solutions, one of the main problems is that they all want users to be on the same domain and login with that domain email. However our app is like facebook or linkedin. Everyone uses different emails / domains. Users login with a username and password not a domain email.

If I setup something like ADFS dump the users in there then spin up something like thinktecture's Identity server V3 to play gatekeeper can I allow logins with username / password and now email? Will this truly act as a one stop shop for SSO? I'm really looking for some guidance to be my own identity provider and support all the major SSO vehicles without having to pay for some overpriced SSO service like Ping or Auth0.

Thoughts?

DasAmigo
  • 333
  • 3
  • 12

2 Answers2

2

So some corrections.

AD is not an enterprise grade solution on its own - you need something on top of it like ADFS.

There is no such thing as Azure ADFS - there's Azure AD which you can think of as combining the functionality of AD and ADFS.

To use ADFS, you need the users in AD. idsrv3 does not have an AD authentication component - although you could write your own extension.

Auth0 sounds like a good solution - I'm puzzled by why you don't want to pay for that but are considering OpenAM which you pay for as well. Shibboleth is free but doesn't support the whole range of what you require.

Refer to:

Because of the range of user inputs you require - upn / email etc. the best bet is to use idsrv3 and extend it. Note that you don't need both ADFS and idsrv3 since they are both IDP. However, you could federate them which would allow the AD functionality without having to rewrite it.

rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • Although IdSrv3 can act as a SAML2 SP with Kentor.AuthServices, there's no support for acting as a SAML2 Idp. A module for that can certainly be built, based on AuthServices, but it's a lot of work. – Anders Abel Dec 10 '15 at 07:34
  • True but SAML is more an enterprise concept than an application one. You could still get into the IDP with WS-Fed or OpenID Connect and exit upstream with SAML. – rbrayb Dec 10 '15 at 17:58
0

Based on your complexity of environment and number of use cases across multiple federation standards, you most likely will find yourself looking at a vendor provided solution for SSO/Federation if it is desired to have a single solution that can be supported. You mentioned Ping and Auth0 which are two very good products that will save you time with integration and ultimately reduce complexity. If you try to go the open source route, you will most likely find multiple products where each is focused at a particular standard and/or integration pattern.

Eric U.
  • 356
  • 1
  • 3