I am implementing a user service that is storing user info in Azure Table storage. I would like to use a value for tenant ID as part of my partition key, but, the claims available in GetProfileDataAsync and IsActiveAsync are just 5 built in claims (sub, name, amr, idp, auth_time).
I get tenant ID from my identity provider and it's included as a claim in both my access token & identity token. How can I make it available to those methods?
When the AuthenticateLocal is invoke, you return an AuthenticateResult to indicate the authentication outcome. If it's successful you use the ctor overload that accepts the subject and name values. There's also an optional claims collection. If you pass values for claims then you are adding your own custom claims to the authentication cookie at IdentityServer. Those claims are then part of the Subject for the GetProfile API (assuming the requests into those APIs are being done via the browser such as from the authorization request). You can then inspect those claims and use them in any way you want.
If the request is not via the browser, then the only claim you have on the Subject is the user's unique id (which is the sub claims).
Related
I'm currently working on configuring Keycloak as a federated identity provider to test the OIDC back-channel logout flow.
In both id token and the logout token, they don't include the sid claim by default since it is an optional claim. But in the client's configuration, there's a config to enable the session identifier in the back-channel logout token. Config to enable 'sid' claim. If this is enabled, the logout token will have an sid claim, but the id token won't.
OIDC Specification section 2.1,
backchannel_logout_session_supported:
OPTIONAL. Boolean value specifying whether the OP can pass a sid (session ID) Claim in the Logout Token to identify the RP session with the OP. If supported, the sid Claim is also included in ID Tokens issued by the OP. If omitted, the default value is false.
According to this, if the sid claim is included in the logout token, id token should also have the sid claim
Is there a way to include sid claim in the id token as well ?.
If not, what's the purpose of having an sid claim only in the logout token and not in the id token ?
I'm not familiar with the back-channel flows, but in general you want to use KeyCloak's concept of "Mappers" to add claims into tokens. Both Identity Providers and Clients can have Mappers, depending on where you need to add data.
Clients and IdP configs will have different 'Mapper Types' available. The 'Mapper Type' field is the most important field when configuring the Mapper - it determines where the data is coming from (some session value, some user attribute, etc). We often have to write small custom implementations for new mapper types to pull some data out of the Java layer so we can put it into a token.
I'm using a custom policy in Azure ADB2C to authenticate and authorize users to my API backend. This works fine.
Now I want to add an additional "aud" entry to the Azure ADB2C jwt token such that I can use the same token for a different service which expects this aud entry to be present.
Right now Azure ADB2C fills in the "aud" field with the ApplicationID for which it was created.
Is there a way to add a static entry to the "aud" field in Azure ADB2C?
Based on your description, I think you are expecting to use the same token to access multiple services (please correct me if my understanding is wrong). Unfortunately, you cannot do this.
A token can only correspond to one scope. The access token is issued according to the api audience you want to access, and it is unique! A token can only have one audience, and you cannot use multiple scopes to request access tokens. If you need to access other services, you should obtain a token for each service separately.
Update：
You can put multiple apis of the same type in the scope because they are still of the same type in essence. But it is not acceptable to request the same access token for two different types of APIs.
test1：
test2：
The Kubernetes documentation related to OpenID Connect mentions that as part of setting things up you need to supply some parameters to the API server:
--oidc-client-id: A client id that all tokens must be issued for.
There is no other explanation about how this would map to, say, something returned by the OpenID Connect-conformant Google identity provider.
I don't know what this parameter value will be used for. Will it match against something in the decoded JWT token?
It looks like the id_token returned by the Google identity provider might contain something, once decoded, in its aud field (aud is apparently short for "audience"). Is this what the --oidc-client-id should match? Am I way off?
This can be explained from the kubernetes documentation on id tokens.
As you can see, identity provider is a separate system. For example this can be MS Azure AD or Google as you have shown.
When you register for a identity provider, you get important things in return. client id is one such important parameter. if you are aware of the openid connect flow, you need to provide this client id when you follow the flow. If the flow is complete, you will return an id token. An id token has one must have claim, aud which is the audience that token was issued for.
When you validate an id token you MUST verify you are in the audience list. More can be found from the spec.
Quoting from specification,
The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience
Now, kubernetes uses bearer tokens. Here the tokens used are id tokens. To validate the token it should know specifically the audience. This enables the API server to validate the token is issued for the particular client who made the call. Thus authorising the call to to success.
I have used IdentityServer3.EntityFramework library to keep all configuration in SQL database. Also I'm using IdentityServer3.AspNetIdentity plugin for identity management. I can't find out how to link / map these 2 database together. I mean base on which concepts.
Do I need to have UserId in Config database or should I match user claims with config claims ?
The claims in the ASP.NET Identity database are claims about that user. This will include a claim type and a claim value (e.g. given_name and scott).
The scope claims within the IdentityServer scopes are what claim types a token can contain if the token has that scope. This is only ever a claim type (e.g. if I request a token with the profile scope, it can contain a users given_name).
The client claims within the IdentityServer client applications are what hardcoded claims that client application will receive in a token. This will include a claim type and a claim value (e.g. client_name and mvcapp).
If your request from client application contains scopes, you store them as role/claims in asp.net identity database. Then compare with scope table in IdentityServer3.EntityFramework database.
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.
IdentityServer issues tokens using OpenID Connect. Issued tokens are ID Tokens and Access Tokens.
Tokens are requested - as stated by OpenID Connect protocol - to clients by using OAuth 2.0 flows. One flow for each client.
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)
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.
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).
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:
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?
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?
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?
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?
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
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.