1
votes

Within our organization, our applications are registered as RP’s to our organizational ADFS server, which is v2. Traditionally, apps in the org have been built as single, monolithic apps using WS-Federation (passive authentication). Web API’s, also hosted within each app, are secured simply by the fact that the same FedAuth cookie is being sent over the wire when making the ajax calls from the app’s client-side code in the browser.

We are moving towards building a set of backend Web API’s, which we want to secure so that these are callable by any client, not just a web browser and not just by the hosting application itself. As such, we want to move towards using JWT tokens for these Web API’s. We've also started using ThinkTecture's IdentityServer (v2) to help in this regard.

We have just a few questions which I'm hoping the community can help provide us with some answers/pointers:

  1. How should we configure IdentityServer and apps so that the apps use the existing organizational ADFS login page?
  2. How can we configure/integrate ThinkTecture IdentityServer v2 with the organizational ADFS so that our API's can be secured using JWT tokens but without forcing the user to provide their credentials again (once they have a SAML token via WS-Federation)?
  3. Are there any features in IdentityServer v3 which are compelling enough to upgrade from IdentityServer v2 to v3?
1

1 Answers

0
votes

1 & 2 - You might want to check out how to establish Relying Parties. Here's a whole article from BrockAllen (the genius behind IdentityServer) that walks you through the ADFS/IdentityServer2 integration.

http://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/

3 - As far as I know, IdentityServer3 (IS3) was written to support newer authorization frameworks OpenID for the modern stack better than IS2 (which doesn't support OpenID). Either is fine for use. I personally started with IS3, mainly because of the support and documentation involved. It also integrates very well with OWIN/Katana, so it can self host reasonably well with no hiccups during implementation and deployment. One advantage IS2 has over IS3 is that IS2 has an admin UI you can use configure and register sites, IS3 doesn't. More info about this along with the thought process behind IS3 can be found here:

http://leastprivilege.com/2015/01/25/identityserver3-1-0-0/