How Cyral authorizes a user to connect to a repository
When a user attempts to connect to a repository using a specific database account, after successful password (token) validation, Cyral follows the sequence below to determine whether to allow the user to connect. If the connection is not successfully authorized, it will be terminated.
If there is an active, granted approval for the user for the repository and database account, the connection is authorized on the basis of this approval.
Otherwise, the access rules for the account are considered in order until a rule matches (that is, this process stops when the first matching rule is found). To match, a rule must meet these conditions:
the rule must be currently active (based on its
the rule's dentity value (username, email, or group) must match the user's SSO identity. (The user will have already authenticated through SSO.)
If a matching rule is found, Cyral enforces its access conditions, if any. The access conditions can include:
a requirement for an active PagerDuty shift and/or
a requirement that the user completes a multifactor (MFA) authentication.
The user's connection request is granted if all the conditions pass, or if there are no access conditions attached to the rule.
The connection attempt is rejected if no matching access rule is found.
After Cyral authorizes any connection using the sequence listed above, it applies your Cyral policy (if any) to determine which fields and data the user can see and use in the repository.
A matched access rule provides the group name for policy enforcement
If your environment includes a Cyral policy with rules that apply to
specific SSO groups,
then Cyral tries to find a policy rule with an
identities: groups value that matches
the SSO group name of the access rule that established the user's connection.
For example, if a user connects via the access rule for the SSO group,
analyst, then the group-specific policy rule that matches (if any)
will be one that lists
analyst in its
identities: groups list.