Recommended
More Related Content
Similar to Wiring up episerver for sso with identity server 4
Similar to Wiring up episerver for sso with identity server 4 (20)
Recently uploaded
Recently uploaded (20)
Wiring up episerver for sso with identity server 4
- 1. WIRING UP EPISERVER FOR SSO WITH IDENTITYSERVER 4 Eric Herlitz @ericherlitz herlitz.io
- 2. IDENTITYSERVER, STS – OR IDENTITYWHATEVER Auth server (STS) Resource owner App / Web Resources User repositories
- 4. THE SCENARIO Login IdentityServerEpiserver Protected external API Resource owner Episerver Already logged in return token WebsiteResource owner Website
- 5. TYPICAL PARTS OF IDENTITYSERVER Clients, registered applications that can request tokens User repositories, membership/identity/external repositories ApiResource, claims are included in TokenClient and IntrospectClient requests IdentityResource, claims are included in UserInfoClient requests
- 7. ACCESS TOKENS - BASICS Access tokens come in two flavors - self-contained or reference.
- 8. SELF-CONTAINED TOKEN (JWT) Auth server (STS) Resource owner App User repositories 1 2 2 3 3 1. Action that needs permission / login 2. Call the STS to validate the credentials 3. Return JWT with claims
- 9. REFERENCE TOKEN (JWT THROUGH INTROSPECT) Auth server (STS) Resource owner App User repositories 1 2 2 3 3 1. Action that needs permission / login 2. Call the STS to validate the credentials 3. Return reference token 4. Introspect call with JWT in return 4
- 10. DEMO Tokens
- 11. WHERE DO YOU GO FROM HERE? http://identityserver.io/ @ericherlitz, herlitz.io All samples available at https://github.com/Eric Herlitz/Identityserver4- Episerver-Demo
Editor's Notes
- Whos using IdentityServer of any version today?And IdentityServer4? So this is going to be a very brief walkthrough of the involved technologies, the basic goal is to give you an idea of what this is. The solution I'm showing is already available for download at my github repository.
- Alright, so this is the typical diagram you'll see on this. Seems easy enough right but what does it mean. First of all the user repositories can be pretty much anything when using IdentityServer. It can be ADFS, ASP.NET Identity or Membership or any other member provider that allow integrations. What is the goal with all of this? Now what we are trying to do is to centralize sign in or authentication having authentication as a service with federation gateway possibilities to connect external identity providers. Does that make sence? Next up is a demo where we will show SSO between Episerver, a .net core web site and a web api.
- So what we just witnessed was a resource owner logging on to Episerver through IdentityServer, we got a token and used that to be authenticated and also used the same token to authenticate an external web api. The same login session was used to authenticate another web application that also could communicate with the secured api.
- Clients, registered applications that can request tokens User repositories, membership/identity/external repositories as already mentioned ApiResource, so when performing a TokenClient request the claims is returned in accordance with the settings of the ApiResource IdentityResource, claims are included in UserInfoClient requests. When you need more information from a user. Applications, the resources using the above. I.e. the implementations we do
- Why use reference tokens? They are small and fast Resources can individually cache them A JWT token would be a self-contained access token - it’s a protected data structure with claims and an expiration. Once an API has learned about the key material, it can validate self-contained tokens without needing to communicate with the issuer. This makes JWTs hard to revoke. They will stay valid until they expire. When using reference tokens - IdentityServer will store the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to IdentityServer to validate the token. http://docs.identityserver.io/en/release/topics/reference_tokens.html
- A JWT token would be a self-contained access token - it’s a protected data structure with claims and an expiration. Once an API has learned about the key material, it can validate self-contained tokens without needing to communicate with the issuer. This makes JWTs hard to revoke. They will stay valid until they expire.
- When using reference tokens - IdentityServer will store the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to IdentityServer to validate the token. IdentityServer provides an implementation of the OAuth 2.0 introspection specification which allows APIs to dereference the tokens.
- This is a very lightweight application for demonstration purposes I threw together. There are a few useful functions and we don't want to open a browser to login so we will login directly through the TokenClient.