I have configured a user my_user who belongs to my_group in Keycloak 4.8.3. I have then obtained an id token for it with grant type Resource Owner Password Credentials (ROPC). When I inspect the issued id token with a tool such as jwt.io I can see that the user's id and name are included as JWT clains sub and preferred_username respectively.
But where does group membership show up inside the JWT?
You need to create mapper. In Keycloak Admin Console go to Clients, choose your client, tab "Mappers", click Create in the header of the grid. In Mapper type combo choose Group Membership and fill other data (Name, Token Claim Name).
Related
I entered the following data, but after applying these settings, the input is not carried out, several questions arise. during authorization, the user returns to the page with minio and so on indefinitely
MINIO_IDENTITY_OPENID_CONFIG_URL=https://test.local.ru/.well-known/openid-configuration
MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
MINIO_IDENTITY_OPENID_CLAIM_NAME=policy
MINIO_IDENTITY_OPENID_CLIENT_ID="292085223830"
MINIO_IDENTITY_OPENID_CLIENT_SECRET="12344556"
MINIO_IDENTITY_OPENID_SCOPES=openid
MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC==https://minio.local.ru/*
how do I even understand why it brings me back to the page? are
there any logs, I don't understand how to debug
do I still need to have policies and users that are in sso? if you start, then you need to specify the access key. It is unclear why authorization is needed then. if you still get the keys to enter.
is it possible to enable both OpenID and standard authorization at the same time?
I finally figured out this problem
you need
to go to the rules section in your keycloak sso client to create a role with a name equal to the policy from the minio:
for example role name
consoleAdmin or readonly
in addition to the name, you do not need to fill in any attributes in the role, do not put it as a composite
after adding the role, we need to perform two steps
create a claim name (the name can be any), for example, minio-roles
mapper type - user client role
claim json - string
client id - the name of your sso client
token claim name - minio-roles
then it remains to assign this role to users in the users section
user - role mapping - client roles ( select client name SSO) - select the right role for this user
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.
In keycloak, there is a default client which client id is “admin-cli”. I try to add a buildin claim into this client.
In Mappers tab under this client, I add buildin mapper “realm roles”. But when I get the JWT from this client using the API:
http://{{url}}/auth/realms/{{realm}}/protocol/openid-connect/token
with proper client_id, the JWT doesn’t include the claim.
I created another client and add the same mapper with same configuration, JWT requested from that client includes the claim.
Any idea why the claim not shown in JWT from client “admin-cli” ?
Any idea why the claim not shown in JWT from client “admin-cli” ?
Yes, you need to:
Go Master Realm;
Clients;
Click on Admin-cli;
Switch to Scope;
In admin-cli Scope Mappings: Set Full Scope Allowed to ON.
This will make all the Realm and Client roles to show up on the Token. If you only need some specific roles then do the following:
Go Master Realm;
Clients;
Click on Admin-cli;
Switch to Scope;
In admin-cli Scope Mappings:
Select the Realm Roles (or client roles) and move then to Assigned Roles column.
I am using a javax filter which gets a HttpRequest from keycloak server if the user has successfully authenticated.
From the request I was able to get the Id token and on decoding this group name is missing from the id token.
How to map the group name information in id token ?
Fixed. Had to add a new group mapper for my client under mapper tab
According to the documentation, the ID token (a JWT token) created by Cognito upon user authentication is also supposed to contain the custom attributes defined for the user's User Pool.
It seems that when the User Pool is configured with a SAML identity provider, the ID token does not contain those custom attributes of the user pool, but only the Cognito attributes which are mapped from the SAML token.
Note: the custom attribute is already configured when the user pool is created, therefore it does not make sense to set it up again in the SAML token, for example by configuring the remote AD FS attributes.
Is there any way to preserve a User Pool custom attribute in the ID token, in this case of using a federated identity provider?
Or be able to hook into the authentication process to insert a custom attribute into the token?
Thanks for the help!