[Question] When should user account roles be looked up?

[DarshitChanpura]

User Account Roles lookup

Background:

User role lookup is one of the key features of the security plugin in OpenSearch service. It is used to map users to specific roles that control their access to data and resources.
The user role lookup process starts with the user authenticating to the OpenSearch service, using one of the supported authentication mechanisms, such as username/password, LDAP, or SAML. Once the user is authenticated, the security plugin looks up the user's roles based on the user's attributes or group membership. The security plugin provides a number of built-in role types, such as superuser, cluster_admin, index_admin, and read-only. Administrators can also define custom roles that grant specific permissions to users based on their needs.
The user role lookup process is an important part of OpenSearch security, as it allows administrators to control access to sensitive data and resources based on the user's role and permissions. By defining granular roles and permissions, administrators can ensure that users have access only to the data and resources they need to do their jobs, while keeping sensitive data secure.

Current Authorization Flow:

The user authorization flow in the OpenSearch security plugin occurs in the following sequence:

1. Once the user is authenticated, the security plugin looks up the user's roles based on the user's attributes or group membership. This involves mapping the user's identity to one or more roles that control the user's access to data and resources.
2. Once the user's roles have been determined, the security plugin enforces role-based access control (RBAC) to determine whether the user has permission to perform a particular action. RBAC is a method of restricting access to resources based on the roles that users have been assigned.
3. In addition to RBAC, the security plugin supports fine-grained access control, which allows administrators to define custom roles and permissions for specific users or groups.
4. As a final step, audit logging feature allows administrators to monitor user activity and detect any unauthorized access attempts.

Proposal Implementation for User Roles lookup inside the new Security Model:

Here are two possible implementations for the roles look-up:

1. Early Lookup: (Current Implementation) (Recommended)
   In this mechanism, user roles are looked up immediately after successful authentication and will be plugged into the user that
   will be placed into ThreadContext

   1. Pros:
      1. Minimal changes to current implementation
      2. The support for existing authentication/authorization backends will not be hindered
      3. No extra API requests required to do role lookup
   2. Cons:
      1. Information overload/scope creep as all user roles will have to be passed as part of the “on-behalf-of” token outside trust boundary. (Can be sent as encrypted values if required in future)
      2. Unable to selectively pass the roles inside the token as there is no knowledge of which roles will be required during authorization
      3. Need to handle scenarios where a user may have large number of roles associated with them

2. Lazy lookup: (Complex and Not Recommended)
   In this mechanism, we delay user role-lookup until the authorization is triggered. We then look-up roles to populate the user just before privilege evaluation happens.

   1. Pros:
      1. Only minimal information is passed in “on-behalf-of” token
      2. Will save some network capacity
   2. Cons:
      1. Extra API call required to do role-lookup. Might result in a duplicate effort for IdPs like SAML which already provide user info upon successful authentication
      2. Will not be able to support external IdPs like SAML, OIDC without setting up an extra mechanism to retrieve user info (e.g. SAML assertions).
      3. Will be a step down from current security model.

Recommendation:

Early lookup : As this option requires minimal changes with a trade-off of all values being passed outside trust boundary. However these values can be encrypted if needed in future.

[peternied]

+1 to the Early Lookup: (Current Implementation) (Recommended) option

[stephen-crawford]

[Triage] This issue is part of the ongoing work with the extensions project.

[davidlago]

Closing as we have a recommendation/straw man and no heated debate in favor of the other option.