Authentication
Authentication is the process of verifying who an entity (such as a user) is. Ververica Platform does not manage user credentials directly; it delegates authentication to an external identity provider using OpenID Connect (OIDC) or Security Assertion Markup Language (SAML).
For base OIDC and SAML setup — including how to enable SSO and configure an initial admin user — see Configure Single Sign-On in the installation guide.
Group Claim Configuration
Ververica Platform 3.1.1 restores support for extracting group memberships from the identity provider token or assertion. Once configured, these groups can be used for role assignments, letting administrators manage access through identity provider groups rather than individual user entries.
OIDC
Add groupsClaim to your OIDC configuration. The value must match the name of the ID token claim that contains the user's group memberships.
global:
authentication:
oidc:
enabled: true
clientId: {your-client-id}
clientSecret: {your-client-secret}
discoveryUri: {your-discovery-uri}
groupsClaim: groups
The claim value must be an array of strings or a comma-separated string. For example, an ID token containing:
{
"sub": "user@example.com",
"email": "user@example.com",
"groups": ["platform-editors", "data-team"]
}
exposes the groups platform-editors and data-team for use in role assignments.
The claim must be present in the ID token. Claims in the access token are not supported, because access tokens have no standardized claim structure.
Provider Examples
Azure Entra ID
Azure Entra ID can include a groups claim containing object IDs of the user's security groups. To use human-readable names instead, configure app roles in the Azure application registration and assign users or groups to those roles. App roles are emitted in the roles claim:
groupsClaim: roles
See Known Limitations for important caveats about Azure AD token size.
AWS Cognito
Cognito includes group memberships in the cognito:groups claim:
groupsClaim: "cognito:groups"
Ensure the Cognito user pool groups are populated and that the ID token is requested with the appropriate scopes.
Dex and Google Workspace
When using Dex as an OIDC bridge with Google Workspace group sync configured, Dex emits group memberships under the groups claim:
groupsClaim: groups
Generic OIDC
Set groupsClaim to the name of the claim your provider includes in the ID token. Consult your identity provider's documentation to identify the correct claim name, and inspect an issued ID token to confirm the value format.
SAML
Add groups-attribute nested under identity-provider in your SAML configuration. The value must match the name of the SAML assertion attribute that contains the user's group memberships.
global:
authentication:
saml:
enabled: true
identity-provider:
groups-attribute: groups
metadata: |
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor ...>
...
</md:EntityDescriptor>
service-provider:
entity-id: {your-service-provider-entity-id}
keystore:
certificate: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
private-key: |
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
The attribute value must be an array of strings or a comma-separated string. For example, an assertion containing:
<saml:Attribute Name="groups">
<saml:AttributeValue>platform-editors</saml:AttributeValue>
<saml:AttributeValue>data-team</saml:AttributeValue>
</saml:Attribute>
exposes the groups platform-editors and data-team for use in role assignments.
Known Limitations
Groups Must Be Present in the ID Token
For OIDC, groups must be present in the ID token. If your identity provider places group information only in the access token, configure it to also include the groups claim in the ID token.