Authentication and Identity¶
Every request to a ODAS service performs the following steps:
- Authenticates the username.
- Looks up the set of groups that the user belongs to.
- Using those groups and the permissions database, authorizes the request.
The above sequence occurs regardless of the configured authorization.
User and group management occurs outside of Okera, and that information is accessed via integrations with supported identity services like Active Directory (AD) or LDAP.
A user has the union of permissions of all the groups that they are in. Okera supports multiple methods for authenticating users and for resolving the set of groups that a user belongs to. Details about those methods as well as limitations on which can be used in conjunction follows.
Okera can authenticate a user via:
Okera accepts that multiple methods will be enabled in a typical configuration. For example, batch applications may prefer JWTs but end-users may prefer AD/LDAP or OAuth.
Currently, Okera resolves the groups that a user belongs to in one of the following ways:
By reading the user's groups from the supplied JWT token. In this case, group names are case insensitive.
By querying an external REST service. In this case, group names are case insensitive.
By querying the configured LDAP server for group membership for the specified user. In this case, group names are case insensitive.
In this case, case sensitivity pertains to the process of comparing the names of groups that a user is a member of to the names of groups that were granted a given role.
A case-insensitive comparison would result in the names
ADMIN being viewed as equivalent where a case sensitive approach would consider those each unique.
You can require all users who want to use ODAS to be in a specific group in order for them to access ODAS. This setting will be enforced for all users of the ODAS cluster, except for Catalog Administrator privileges who are exempt from this check.