Repository navigation
Issue 38664 contextual mac algorithm - #54482
jimmychakkalakal wants to merge 3 commits into
Conversation
96e854d to
091508b
Compare
037b06e to
04e6726
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Switching from private_key_jwt to client_secret_jwt can retain and submit an incompatible RS256 value despite a blank selection, while the shared tooltip misstates the default and contextual label tests remain incomplete.
3 open issues
What changed in this PR
Updates Admin Console terminology to distinguish symmetric MAC algorithms from asymmetric signature algorithms, extending the clarification from #48988 to contextual client settings and related documentation.
Changes:
- Adds selection-dependent labels and tooltips to advanced OpenID Connect settings.
- Uses MAC terminology for client-secret JWT authentication and filters identity-provider options to symmetric algorithms.
- Updates administrator documentation and adds Credentials-tab regression tests.
| File | Description |
|---|---|
js/apps/admin-ui/test/clients/details.ts |
Adds helpers for algorithm labels and options. |
js/apps/admin-ui/test/clients/details.spec.ts |
Tests MAC versus signature terminology in Credentials. |
js/apps/admin-ui/src/identity-providers/add/OIDCAuthentication.tsx |
Adjusts assertion labels and options by authentication method. |
js/apps/admin-ui/src/clients/credentials/SignedJWT.tsx |
Uses MAC labels for client-secret JWT authentication. |
js/apps/admin-ui/src/clients/advanced/FineGrainOpenIdConnect.tsx |
Makes algorithm labels and tooltips selection-dependent. |
js/apps/admin-ui/maven-resources/theme/keycloak.v2/admin/messages/messages_en.properties |
Adds contextual labels and key-usage explanations. |
docs/documentation/server_admin/topics/identity-broker/oidc.adoc |
Clarifies OIDC client assertion algorithms and defaults. |
docs/documentation/server_admin/topics/identity-broker/oauth2.adoc |
Clarifies OAuth2 client assertion algorithms and defaults. |
docs/documentation/server_admin/topics/clients/oidc/con-confidential-client-credentials.adoc |
Explains shared-secret JWT authentication using MAC terminology. |
Review effort: Balanced
04e6726 to
374ffb6
Compare
There was a problem hiding this comment.
@jimmychakkalakal Thanks!
IMO the PR is a bit too far. In both client "Advanced setting" options or in the OIDC/OAuth2 Identity provider, I would rather prefer to keep it simpler and use always single label and tooltip.
So for example for "request" object, it is OK for me to keep label like Request object signature algorithm . I agree that Request object algorithm might be more clear as it is more universal, but at the same time, the OIDC specification uses name like request_object_signing_alg . At the same time, it might be good to just update tooltips and make them more clear that in case of HS algorithms, the term "signing" is maybe not so accurate? So maybe the tooltip could be something like:
JWA algorithm used to sign/authenticate an OIDC request object sent in the 'request' or 'request_uri' parameter. Asymmetric algorithms use a client private key to sign request object; HS algorithms use the client secret to create HMAC of a request object.
For OIDC/OAuth2 identity providers, it is maybe OK to use single option and just change it for the universal Client assertion algorithm . So basically align the behavior according to how you documented it (see my inline comments for the documentation).
| |Client Assertion Signature Algorithm | ||
| |Signature algorithm to create JWT assertion as client authentication. | ||
| In the case of JWT signed with private key or Client secret as jwt, it is required. If no algorithm is specified, the following algorithm is adapted. `RS256` is adapted in the case of JWT signed with private key. `HS256` is adapted in the case of Client secret as jwt. | ||
| |Client Assertion Algorithm |
There was a problem hiding this comment.
This documentation looks correct to me. However the behavior in the admin console is not aligned with that. It seems what admin console does is that option name is changing dynamically between Client assertion signature algorithm or Client assertion MAC algorithm according to which "Client authentication" method is selected.
IMO it would
8000
be easier to keep the documentation and rather simplify the logic in the admin console. So that the admin console in the IDP page will have just option Client Assertion Algorithm with the tooltip aligned to what you mentioned in this documentation. The option will allow both signing and MAC algorithms.
| |Client Assertion Signature Algorithm | ||
| |Signature algorithm to create JWT assertion as client authentication. | ||
| In the case of JWT signed with private key or Client secret as jwt, it is required. If no algorithm is specified, the following algorithm is adapted. `RS256` is adapted in the case of JWT signed with private key. `HS256` is adapted in the case of Client secret as jwt. | ||
| |Client Assertion Algorithm |
There was a problem hiding this comment.
Same like previous comment from oauth2.adoc
Closes keycloak#38664 Signed-off-by: Palash Thakur <117917450+palasht75@users.noreply.github.com> # Conflicts: # js/apps/admin-ui/test/clients/details.spec.ts # Conflicts: # js/apps/admin-ui/test/clients/details.spec.ts
Signed-off-by: Jimmy Chakkalakal <jimmy.chakkalakal@ibm.com>
374ffb6 to
80fa460
Compare
Co-authored-by: Palash Thakur <117917450+palasht75@users.noreply.github.com> Signed-off-by: Jimmy Chakkalakal <jimmy.chakkalakal@ibm.com>
80fa460 to
69dfe4e
Compare
| membershipUserLdapAttributeHelp=Used only if the Membership Attribute Type is UID. It is the name of the LDAP attribute on the user, which is used for membership mappings. It is typically 'uid'. For example, if the value of 'Membership User LDAP Attribute' is 'uid' and the LDAP group has 'memberUid\: john', it is expected that particular LDAP user will have the attribute 'uid\: john'. | ||
| samlCapabilityConfig=SAML capabilities | ||
| accessTokenSignatureAlgorithmHelp=JWA algorithm used for signing access tokens. | ||
| accessTokenSignatureAlgorithmHelp=JWA algorithm used to sign/authenticate access tokens. Asymmetric algorithms create a digital signature with a realm private key; HS algorithms create an HMAC with a realm secret key. |


Summary
• Clarifies algorithm labels in the client’s advanced OpenID Connect settings.
• Shows “MAC algorithm” for symmetric choices, “signature algorithm” for asymmetric choices, and a neutral label
when no algorithm is selected.
• Updates the tooltips to explain which key is used for each algorithm type.
This addresses the terminology concern raised in PR #48988 (#48988) for client settings that offer both algorithm types.
Closes #38664.
Co-authored by Palash Thakur (@palasht75) (https://github.com/palasht75).