CODEWITHSUNDEEP
entity-frameworkasp.net-identity-2identityserver3
Marconline
Marconline

Reputation: 1451

IdentityServer 3 + Asp.net Identity: Scopes, Claims and Clients - Clarifications

I'm almost figuring out how the different pieces of an Authentication and Authorization server architecture work. I really think that IdentityServer is a great piece of software.

I'm trying to summarize my discoveries, to settle a base for my questions.

  1. IdentityServer issues tokens using OpenID Connect. Issued tokens are ID Tokens and Access Tokens.
  2. Tokens are requested - as stated by OpenID Connect protocol - to clients by using OAuth 2.0 flows. One flow for each client.
  3. During the flow beginning, client requests a collection of scopes (at least "openid", that's because he has to state that an OpenID Connect flow has been activated)
  4. A client may ask all the scopes that he is authorized to ask. Using the Entity Framework plugin for IdentityServer, this information is contained in the ClientScope table. If the client requests a scope that he isn't authorized to request, the flow is interrupted.
  5. Scopes may "contain" claims. This means that if a scope contains a group of claims, whenever the client is issued a token, this token contains also all the corresponding user's claims. For example: let call "roles" a scope that contains "role" claim. As soon as the client is authorized, the received token will contain all the user's roles (as claims).
  6. Each requested scope, if authorized, is "translated" in a claim with the name "scope". This means that if a client requests, for example, a defined "api" scope, the generated identity will have at least a claim called "scope" with value "api".

If all of what I've written is more and less correct, here are my questions:

  1. how are claims defined on asp.net identity tables (i.e. AspNetUserClaims) connected to the IdentityServer ones. For what I've seen the matching is made on the name. Is this conclusion correct? In other words, if my client has to receive a "role" claims (because he has asked for the "roles" scope), will the "Asp.Net Identity" plugin for IdentityServer just release the "role" claims defined for the authenticated user?
  2. referencing the "EntityFramework" plugin tables, what's the meaning of the "ClientClaims" table? I cannot get how claims can be directly connected to client... What am I missing?

  3. let's suppose that in my resource server I've an action protected with a ResourceAuthorize attribute like this:

    [ResourceAuthorize("Read", "Orders")]

    In my AuthorizationManager I check for the presence of a claim "order_read" or a claim "api". Those are two different scopes defined in my AuthorizationServer, one just for "order reading" and the last for a complete API access. The first may be asked by third-party clients, while the latter no. Is that a good practice?

  4. I cannot understand what my client should do with the id_token. Should I ignore the problem, as I'm using the js library OIDC Token Manager? Are the security controls performed by this library?

  5. Last question: when my application presents the Access Token, how is the ClaimsIdentity generated? Is right to say that it's generated after validating the token on the Identity Server? Does this means that IdentityServer will get the access token and translate it in a set of claims?

Thanks for your clarifications!

Marco

Upvotes: 9

Views: 3224

Answers (1)

Brock Allen
Brock Allen

Reputation: 7435

Yep, you got the gist of it. As for your questions:

how are claims defined on asp.net identity tables

That's up to you. IdentityServer doesn't mandate an identity management library. The IUserService extensibility point is where you bridge that gap. We have a starter version of IUserService, but it's a code-based NuGet so you can change it to really do what you need.

I cannot understand what my client should do with the id_token

It is mainly used to pass back to IdentityServer at signout time (to authenticate the signout request).

when my application presents the Access Token, how is the ClaimsIdentity generated

There is middleware (AccessTokenValidation) to validate the access token. The result is the claims form the token, which are then turned into a ClaimsIdentity and then made available to any processing downstream (such as your Web API code).

what's the meaning of the "ClientClaims" table

The Client configuration has a Claims property if you'd like to issue claims on behalf of the client. Check the docs: https://identityserver.github.io/Documentation/docsv2/configuration/clients.html

let's suppose that in my resource server I've an action protected with a ResourceAuthorize attribute like this

This is unrelated to IdentityServer, and is part of the IdentityModel library. ResourceAuthorize is a framework for using the user, the resource, and the action being performed into account when trying to decide the authorization outcome.

Upvotes: 7

Related Questions