I have a Keycloak Client where i am receiving my Access Tokens. I have created a few mappers to gain some additional informations out of the Access Token.
With the Group Membership Mapper type i can also receive the Group names as an array, where the user is a member of. But i want to have the IDs of the Groups.
Is it possible to add those to the Token instead of making an additional API call to Keycloak?
Related
I have two realms, a public webapp and an extranet where only employees can access.
I have tried setting group policies.
When I try to connect with an non-employee user, keycloak still returns the access token.
What did I miss?
EDIT.
I made a mistake, I only have 2 clients.
You have to limit the access granted to your access token to achieve this. There are three ways to do it (that I know of)
Audience: Allows listing the resource providers that should accept an access token.
Roles: Through controlling what roles a client has access to, it is
possible to control what roles an application can access on behalf
of the user.
Scope: In Keycloak, scopes are created through client scopes, and an
application can only have access to a specific list of scopes.
You can look at this example which explains the flow on how to achieve this using role based method. You can refer this as well.
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：
I'm using SAML for login into my app, I would like to include the user groups in attributes in the login response assertion. I'm wondering if the login request should specify that the attribute is required, or if this is a configuration that needs to be done on the IDP in general, or in the IDP specifically for my service provider.
I've created Identify Provider in OpenAM and have my own APP Service Provider configured in OpenAM as remote SP as well, I've also created a user in OpenAM and assigned it to a group, however, I'm not seeing the group in the response assertion, even when I tried to map the value in OpenAM manually, the memberOf attribute always returned empty.
Any information will be highly appreciated.
Shay
The best answer I have for you, is that there is no good way to share group membership information in SAML2 assertions OOTB.
I would suggest to implement a custom attribute mapper and implement the retrieval of group membership data there, but you will find that the DataStoreProvider interface does not expose group membership related operations, so you would need to directly use the AMIdentity/AMIdentityRepository API in your plugin.
When it comes to group memberships you have a couple of choices:
return the names of the groups
return the DN of the groups
return the Universal ID of the groups (universal IDs are OpenAM's internal unique IDs that is stored in DN format, but it is not the same as the groups DN in the directory server)
The first option would be my personal recommendation as that fits into OpenAM's abstract user data store concept.
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).
I was told that it is possible to give information about group membership during a SAML authentication request. We have to connect to an application that does use SAML (we are at the end that is creating the SAML answer XML). Authenticating a user works fine but I can't find a way to specify a "member of" or similar attribute.
Can you explain to me how to pass group memberships in SAML during authentication or have an example ?
I know there is a possibility to take care of authorization in SAML at a socalled Policy Decision Point. But this would mean that a SAML flow would happen for each or some (if batched) entities we want to check authorization for.
Let me give you an example what we are trying to do. This example is made up but shows the problem we want to solve.
Let's assume you have a hard drive with lots of directories and files on it. We use SAML to authenticate the person that tries to access that drive. Members of the group "admin" are allowed to read and write and members of group "user" are only given read permission.
Because of this we want to send the group memberships of a user when he or she authenticates. Because otherwise it would mean that the application has to check for every file if the user is in the necessary group. If it was clear from the beginning (after authentication took place) that someone is a member of a specific group the application can cache that in memory.
As with most things in SAML, this depends on the identity provider as well as the application.
Many identity providers have access control to allow or deny specific users or groups to access an application. Sign-on is then denied by the IdP after authentication based on the ID of the application (from the SAML request) and access control configured in the IdP. If you just want to control who has access to the application, then this is all you need, and most, if not all, identity providers should have you covered.
Sometimes you also want different users or groups to have different permissions inside the application, or you want memberships in certain groups on the IdP to be mapped to membership in groups inside the app's own user and group database (or other application-specific group-like concepts). There is no standard for this, but some identity providers allow the definition of attribute mapping rules based on group membership. For example, in ADFS, you can create a claim rule that sets a specific SAML attribute to a specific value if and only if the user is a member of a specific group in AD. You would then set up such a rule and set a SAML attribute that your application understands to a value it understands.
Alternatively, if an application supports configuration of multiple IdPs, then you can configure one app / IdP mapping per group, and for each group add an attribute mapping rule with a hard-coded group name in an attribute that your application understands.