v26.4.10
v26.4.10
SCIM group reads report the group's membership
A GET on /Groups/{id} now reports the group's current membership in members. Until now it answered with an empty members
list unless the request carried the Polis-specific includeMembers=true parameter, so a standard SCIM client saw every group as
empty and could not tell an empty group from one whose members were not reported.
A group listing still reports members only when includeMembers=true is set, because it resolves one membership for every group
on the page. Without the parameter the attribute is left out of each listed group rather than returned empty.
A group with more members than DSYNC_MAX_INLINE_GROUP_MEMBERS (500 by default) leaves members out of a read as well, so the
group stays readable; includeMembers=true still answers 400 for such a group. Read large memberships through the paginated
GET /api/v1/dsync/groups/{groupId}/members endpoint.
A failure reading the membership store is now reported as an error. Until now a failed read ended the membership walk, so the
response could report fewer members than the group has, or none, with status 200.
Breaking changes
members is no longer always present on a group response. It is absent on a listed group unless includeMembers=true is set, on
a group past the inline limit, and on the response to a create, replace or patch, which report the group rather than its
membership. A client that reads members without checking for it first, for example response.members.length, must guard against
its absence.
Identity federation apps only accept their own registered redirect URLs
An OIDC identity federation app now accepts a redirect_uri only when it is registered on that app. Before, Polis also accepted a
redirect_uri that was registered on the upstream SSO connection the user signed in through, so an endpoint registered to a
different relying party could receive the federation app's authorization code.
If a client of a federation app uses a redirect URL that is registered only on an SSO connection, add that URL to the federation app's redirect URLs. Clients that connect to an SSO connection directly are not affected.
SCIM group PATCH applies operations it used to drop, and no longer clears membership by accident
A PATCH on /Groups/{id} whose operation carries no path and an op of add now applies it: members in the value object
are added to the group, and a displayName renames it. Until now only a pathless replace was applied, while a pathless add
was answered 200 and dropped, so an identity provider recorded a membership change the group never received. An add with a
path of displayName renames the group too, as replace with that path already did.
A replace aimed at any other attribute no longer touches the membership. Until now a value carrying members was applied
whatever the path named, so a request such as {"op":"replace","path":"externalId","value":{"members":[]}} cleared the group's
entire membership and answered 200.
Attribute names in a pathless value are matched case-insensitively, so Members or DisplayName is applied too. As with every
other member list, one that is not a list of objects with a string value is rejected with 400 and the scimType invalidValue
before any operation in the request is applied, and so is a displayName that is not a string, with or without a path.
Unsupported SCIM list filters return 400
Listing users or groups with a filter that is not a single eq comparison now answers 400 with the scimType invalidFilter.
Until now the value was read by splitting the filter on eq , which failed two ways: co, sw, gt and pr raised a server
error, while an and, or or not composition succeeded with 200 and a value taken from the middle of the expression, so it
answered a filter nobody had asked for. Requests of the second kind now return 400 instead of an empty or wrong list.
Filters of the form <attribute> eq "<value>" are unchanged. The operator is matched case insensitively, and a double-quoted
value is decoded as a JSON string, so \" matches a quotation mark, as RFC 7644 requires.