Skip to content

Instantly share code, notes, and snippets.

@pmhsfelix

pmhsfelix/access_control_arch.md

Last active October 20, 2015 06:35
Show Gist options
  • Save pmhsfelix/d72d0b4d714d6c5604cf to your computer and use it in GitHub Desktop.
Save pmhsfelix/d72d0b4d714d6c5604cf to your computer and use it in GitHub Desktop.
Download ZIP
Access control architecture
Raw
access_control_arch.md
  • Use an OAuth 2.0 Authorization Server (AS) to issue access tokens containing (or refering to) the required information, typically the user's identity (i.e. resource owner identity), the client app identity and the authorization scope.
  • The Web API (i.e. the Resource Server) will only accept access tokens from the AS. Namely, the Web API will not have to deal with tokens from the external identity providers.
  • The AS will delegate the user's authentication process to an external identity provider, therefore also acting as an Federation Gateway.
  • If account linking is necessary (e.g. linking two different external accounts to one internal account), then this can be done at the AS level. Otherwise, the AS will only forward the external identity claims into the Web API.
  • IdentityServer 3 can be used to implement both the AS and the Federation Gateway functionality. There is OWIN Middleware available to process access tokens issued by IdentityServer 3.
  • If the Web API is OWIN based (or supports OWIN middleware), then IdentityServer 3 can be deployed along side with it, in the same Web app.
RS --1-> AS --*-> IdentityServers (e.g. Google, WAAD)
@aliostad
Copy link

Thank you, yes this is quite useful.
Any whitepaper on Federation Gateway itself?

@leastprivilege
Copy link

thanks for the write up!

@leastprivilege
Copy link

dude - that's just a token service that brokers trust to other token services. not everything needs a whitepaper :p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment