2

I've found myself before a task I don't even know where to start. So basically I have a working IS4 auth server which has been serving my App and API for some time, and it works great. Our solution supports regular user registration/login and also Google and Facebook logins.

Now we're presented with a challenge from one of our clients to enable their employees to log into our app with their existing AD user accounts. Naturally I don't want to do this just for them, but would like to make it an option for all other enterprise users that have existing ADs. I've been reading about federated gateways and windows login, but will definitely need read more about it.

The major unknown for me is how to allow anyone to connect their AD with my app and then execute login process. Ideally, I would like to do this by having a DB table where I would store all third party AD providers and somehow load them on app start, but if I'll have to manually add code block to my Startup class for each of them, I'll live with it.

Second unknown is the login process itself; do I need to have a separate login page for those companies that use AD, or use the existing one but check if I have a provider registered for that email domain user is logging in with, whenever anybody tries to log in?

Nikola Biondic
  • 135
  • 2
  • 11

2 Answers2

2

Firstly - ADFS on Server 2016 supports OpenID Connect so I'd recommend taking that approach if you can. LDAP is another option but for authentication is much more hassle to implement and just not as good in my opinion.

We allow customers to define policies linked to domains and those policies can support federating authentication to an external OIDC provider. We automatically route the user through the correct flow based on their domain after capturing their email address.

To support this we created a custom OIDC middleware implementation that could take the authority URL and client ID etc as parameters at runtime when calling Challenge().

mackie
  • 4,996
  • 1
  • 17
  • 17
  • Mind sharing some pseudo code of how you made that middle ware? – Peter Karman May 21 '19 at 01:14
  • @PeterKarman The long and short of it was that I created my own subclass of OpenIdConnectHandler and primarily override HandleUnauthorizedAsync and changed it so certain properties (e.g. the authority, client ID etc for the external IDP) came from the ChallengeContext.Properties passed into that method instead of Options object which is defined during Startup. The ControllerBase.Challenge method supports passing in an AuthenticationProperties object which contains a dictionary and thus allows you pass anything you like to the middleware from application code. – mackie May 23 '19 at 15:44
2

If you already have a working setup with your app and IdentityServer as your authentication provider, then you should ask yourself first where you want the integration of other authentication providers to happen: So do you want to allow users of your app to authenticate with the AD, or do you want that to happen at the IdentityServer.

Both are valid approaches but have different effects, and also different implementation implications.

The first option is to have the AD integration within your app. That means that when users sign into your app, they can decide whether to sign in with your IdentityServer, or their AD login. If you choose to do this, then you do not need to touch your IdSrv at all, you just need to add support for another external authentication provider in your app and offer your users to choose. This also means that the new authentication option is specific to your app and will not affect other applications that use your IdSrv. But of course you will have to do this separately for every app.

The alternative would be to add this to the IdentityServer app. Since IdSrv is an ASP.NET Core application as well, this works pretty much the same way there: You offer the users multiple ways to sign in, and then they are redirected back to your app which only has one kind of external identity: the one that comes from your IdSrv. The benefit here is obviously that you do not need to change your apps for this and all apps will automatically inherit the functionality from the IdSrv.

As for the AD login itself: Usually, you won't need to configure this. In order to allow sign in with an AD account, your app server will have to be part of the active directory as well, and it will only be able to sign in for that AD. So you cannot support multiple ADs but only the current.

The login itself often happens through NTLM, in which case you don't need a login page, but the browser will just use the current account or prompt for a login. You can also use a login form but then you will have to sign in with the AD yourself.

Another alternative would be to use ADFS which is Microsoft's own authentication provider for Active Directory (not just that though). In a way it's very similar to IdSrv. When integrating with corporates that use an AD, it's somewhat likely that they would like to deploy an ADFS as well or already run one. So you could integrate with it and just register the ADFS as an external OIDC authentication provider in IdSrv (or your app) and give users the choice.

poke
  • 369,085
  • 72
  • 557
  • 602