The invitation docs only described the registration form. Explain that the
invitee can return to the login page and authenticate through an identity
provider instead, that the resulting membership is unmanaged, and that the
email of the account has to match the address the invitation was sent to.
Note that the invitation is accepted through any identity provider in the
realm, and that a user already linked to the provider skips first broker
login, so the invitation stays pending until it expires.
Signed-off-by: Alexis Rico <sferadev@gmail.com>
Closes#53312
The subject of the notify-user step was passed to the email provider
verbatim, where it ends up as a java.text.MessageFormat pattern when it
does not match a key from the email theme message bundle. A subject such
as "${user.firstName}, log in to keep your account active" therefore
failed with:
IllegalArgumentException: can't parse argument number: user.firstName
The email was never sent, the step was still marked as completed, and
the following steps of the workflow ran as usual.
Resolve properties in the subject with the same resolver already used
for the custom message, and escape the resulting text so that it is not
interpreted as a MessageFormat pattern. Escaping is a no-op for a text
without MessageFormat meta characters, so a subject referencing a key
from the message bundle keeps being resolved and localized as before.
It also makes a subject with a single quote, like "your account's
review", keep its quote instead of silently losing it.
Signed-off-by: Luca Tronchin <ltronky@gmail.com>
* Do not chek critical status for key usage validations.
Provide perovider options for backwards compatibility.
Closes#52982
Signed-off-by: rmartinc <rmartinc@redhat.com>
* Move X509BrowserLoginTest and X509DirectGrantTest to the new CI
Closes#52982
Signed-off-by: rmartinc <rmartinc@redhat.com>
* Migrate tests to the new CI
Closes#52982
Signed-off-by: rmartinc <rmartinc@redhat.com>
* Do not initialize stores is tls is not enabled in ManagedCertificates
Closes#52982
Signed-off-by: rmartinc <rmartinc@redhat.com>
---------
Signed-off-by: rmartinc <rmartinc@redhat.com>
Organization alias validation reused the generic RFC 3986
reserved-character blocklist shared by realms, clients, and IdP
aliases, which is stricter than OAuth 2.0 scope-token syntax
(RFC 6749, Section 3.3). Validate the alias against the RFC 6749
scope-token character range instead, so characters such as '/'
and ':' are permitted.
Closes#50703
Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>
Signed-off-by: Martin Kanis <mkanis@ibm.com>
Co-authored-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>
The role-mappings endpoints filter roles by canView. A manage-users
admin can map non-admin realm roles but lacks view-realm, so the filter
emptied the role mapping tab in the admin console. The same happens with
fine-grained admin permissions when an admin holds map-role on a role
but no view permission on the realm or client. Allow canView to succeed
when the admin can map the role.
Apply the same per-role visibility rule to the client-level
role-mappings endpoints, which returned 403 without a view permission on
the client, and to the realm and client roles of the group
representation.
Closes#52753Closes#52727
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: HerrDerb <truuba@gmail.com>
Signed-off-by: Pedro Igor <pigor.craveiro@gmail.com>
Since 26.6.2 the introspection endpoint validates that the authenticated
client is present in the token's aud claim. Refresh and offline tokens
are issued to the realm rather than to an audience of clients, and
audience protocol mappers do not apply to them, so introspecting a
refresh token without token_type_hint - or with
token_type_hint=access_token - was routed to the access token provider
and incorrectly returned {"active": false}.
Detect refresh and offline tokens from their typ claim and route them to
RefreshTokenIntrospectionProvider, which validates the caller against azp
(issuedFor) instead of aud. Any other caller-provided hint is left
untouched.
Closes#51552
Co-authored-by: tusharsaini18899 <sainitushar18899@gmail.com>
Signed-off-by: Jimmy Chakkalakal <jimmy.chakkalakal@ibm.com>
SCIM POST /Users shares the same creation path as the Admin REST API
(UserProfile.create() -> session.users().addUser()), so a user storage
provider with sync registration enabled can create the user outside of
local storage. If that provider does not import users, the created user
becomes unreachable via subsequent SCIM GET/search/DELETE requests. This
is accepted as a documented limitation of this version of the SCIM API
rather than changed in code.
- Extend the custom-providers UserMapStorage test fixture with a
SYNC_REGISTRATIONS gate (mirroring LDAPStorageProvider), defaulting to
enabled to preserve existing behavior for current consumers.
- Add FederatedUserTest coverage for the three relevant variations: no
sync registration (created locally), sync registration with import
enabled (federated but immediately visible), and sync registration
with import disabled (created but unreachable via SCIM).
- Document the limitation in the SCIM server admin guide's "Creating a
user" and "Deleting a user" sections.
Closes#51735
Signed-off-by: Stefan Guilhen <sguilhen@redhat.com>
A filtered PATCH remove such as "assurance[value eq \"x\"]" resolved to a
null value when the attribute had no complex type, because the filter
converter bailed out early. The null reached the model remover, which
treats null or empty as "remove every value", so all values were deleted
instead of the matched one.
Multivalued attributes without a complex type expose only the "value"
sub-attribute, so resolve the filter against it and let the existing
multivalued mapping turn it into the set of values to remove.
Closes#51525
Signed-off-by: sandaruwijewardhana <sandaruwijewardhana@gmail.com>
Document the verifiable_credential_offer Application Initiated Action,covering configuration, application integration, the QR code flow, and admin-initiated credential offers via email.
Closes#50041
Signed-off-by: Jimmy Chakkalakal <jimmy.chakkalakal@ibm.com>
