Allow OAuth scope characters in organization alias - #53092

The broadened OAuth scope-token character set for aliases newly
allowed '*' and ':', which conflicted with how OrganizationScope
already uses those characters:

- '*' is reserved by OrganizationScope.ALL to mean "every
  organization the user belongs to", so an alias equal to '*' could
  never be selected specifically via organization:*. Reject that
  exact alias value while still allowing '*' elsewhere in an alias.

- SCOPE_PATTERN used a greedy regex that split organization:<alias>
  on the last ':' instead of the first, so alias values containing
  ':' were parsed incorrectly. Made the first group non-greedy so it
  splits on the first separator instead.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…e names by longest match

- Move alias validation into JpaOrganizationProvider.create() so it
  applies unconditionally to the effective alias (after the blank
  name-fallback default), instead of only validating the fallback
  name. The previous placement let realm import
  (DefaultExportImportManager#importOrganizations) persist an alias
  with disallowed characters, since it calls the provider directly
  and never went through OrganizationsResource. The now-redundant
  pre-check in OrganizationsResource is removed since the provider
  is the single enforcement point all creation paths funnel through.

- Replace OrganizationScope's regex-based "name:value" scope
  splitting with a longest-prefix match against the client's actual
  registered scopes. Client scope names are already allowed to
  contain ':' (see ClientScopeResource#scopeNamePattern), so neither
  a greedy nor a non-greedy regex split can correctly separate the
  scope name from the value in every case once alias values may also
  contain ':'. Trying progressively shorter prefixes against real
  client scopes resolves both a colon-containing scope name and a
  colon-containing alias value correctly.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

The session-cached lookup in resolveClientScope returned the first
matching entry from an unordered Set, not necessarily the longest.
Once a shorter scope name (e.g. organization) was cached from an
earlier request, a later request for a more specific overlapping
scope (e.g. organization:team, itself organization-enabled) could
incorrectly resolve to the shorter cached one, corrupting the parsed
value. Track and return the longest matching cached name instead,
consistent with resolveParameterizedClientScope.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…them

StringUtil.isBlank() treats whitespace-only strings as blank, so a
caller-supplied alias like " " or "\n" was being silently replaced
with the org name (the "no alias provided" fallback) instead of
being validated and rejected. Use isNullOrEmpty() for the fallback
decision instead, so only a truly absent alias (null or "") defaults
to the name; any non-empty value, including whitespace-only, is
validated as-is and rejected if invalid.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…meterized scope values with separators

- Rename validateAliasAcceptsBlankOrNull to validateAliasAcceptsEmptyOrNull
  to accurately describe the null/empty inputs it covers.
- Add an OIDC integration test verifying that an organization scope value
  containing the ':' separator (e.g. organization:ABC:Google) still
  resolves to the correct organization.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…auth-scope-chars

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…pfront

Organization aliases are immutable once set (OrganizationAdapter#setAlias
rejects changing an existing alias), so updating the alias after creation
silently returned 400 and left the persisted alias as "orga", meaning the
test never actually exercised a colon-containing alias. Create the
representation with the alias set before the create call instead.

Signed-off-by: TamaraMurazyan <murazyan.tamara5566@gmail.com>

…it tests

Closes keycloak#50703

Signed-off-by: Martin Kanis <mkanis@ibm.com>