Skip to content

Authentication and Identity

Every request to a ODAS service performs the following steps, regardless of which authorization tool is used:

  1. Authenticates the username.
  2. Looks up the set of groups that the user belongs to.
  3. Using those groups and the permissions database, authorizes the request.

User and group management occurs outside of Okera, and that information is accessed via integrations with supported identity services such as 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 these methods, as well as any limitations on which methods can be used in conjunction, are provided below.

User Authentication

Okera can authenticate a user via:

  1. Microsoft Active Directory (AD)/LDAP username and password
  2. JSON Web Tokens (JWT)
  3. OAuth Authentication
  4. SAML
  5. Kerberos

Okera accepts that multiple methods may be enabled in a typical configuration. For example, batch applications may prefer JWTs but end-users may prefer AD/LDAP or OAuth.

Two-factor authentication is also supported if you use OAuth or SAML to authenticate users and if your identity provider (IdP) is configured for two-factor authentication.

Group Resolution

Currently, Okera resolves the groups that a user belongs to in one of the following ways:

  1. It reads the user's groups from the supplied JWT token. In this case, group names are case insensitive.

  2. It queries an external REST service. In this case, group names are case insensitive.

  3. It queries the configured LDAP server for group membership for the specified user. In this case, group names are case insensitive.

Case Sensitivity

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, Admin and ADMIN being viewed as equivalent where a case sensitive approach would consider those each unique.

Required Groups

You can require all users who want to access and use ODAS to be in a specific group. This setting will be enforced for all users of the ODAS cluster, except for Catalog Administrator privileges who are exempt from this check.

Group Resolution via External REST Service

The call to this endpoint is a GET call where the username (of the user for which you want to provide group membership) is either 1) appended to the configured URL and expects JSON as the return value or 2) if the GROUP_RESOLVER_URL_FORMAT environment variable is set, then the first instance of the string {0} will be replaced with the username in question.

As a REST call, it looks like this:

curl -X GET  -H 'Accept: application/json' https://<URL>/<username>
The return value is a JSON list of strings associated with the key groups. Here is a representative payload:

{
    "groups": [
        "cat_person",
        "group1",
        "notadmin"
    ]
}