User info fetcher

This feature is experimental, and subject to change.

The User info fetcher allows for additional information to be obtained from the configured backend (for example, Keycloak). You can then write Rego rules for OpenPolicyAgent which make an HTTP request to the User info fetcher and make use of the additional information returned for the username or user id.

You can enable the User info fetcher sidecar as follows:

apiVersion: opa.stackable.tech/v1alpha1
kind: OpaCluster
metadata:
  name: opa
spec:
  image:
    productVersion: 0.61.0
  clusterConfig:
    userInfo: (1)
      backend:
        keycloak:
          hostname: keycloak.my-namespace.svc.cluster.local
          port: 8443
          tls:
            verification:
              server:
                caCert:
                  secretClass: tls (2)
          clientCredentialsSecret: user-info-fetcher-client-credentials (3)
          adminRealm: master (4)
          userRealm: master (4)
          cache: # optional, enabled by default
            entryTimeToLive: 60s # optional, defaults to 60s
  servers:
    roleGroups:
      default: {}
---
apiVersion: v1
kind: Secret
metadata:
  name: user-info-fetcher-client-credentials
stringData:
  clientId: user-info-fetcher (3)
  clientSecret: user-info-fetcher-client-secret (3)
1 Enable the user-info-fetcher sidecar
2 Enable TLS verification using the CA from the tls secretClass.
3 Obtain Keycloak API credentials from the specified secret. The Secret must have clientId and clientSecret entries.
4 Refer to the applicable realm in your Keycloak server.

Currently the following backends are supported:

Keycloak

Fetch groups and extra credentials, but not roles.

The OAuth2 Client in Keycloak must be given the view-users Service Account Role for the realm that the users are in.

Example rego rule

User-facing API & API stability

Since the 24.07 SDP release we provide an example rego rule in our documentation using an HTTP request. However, our plan is that the user-facing API of the SPD is not the HTTP API of user-info-fetcher, but instead regorules that will automatically be shipped to the OPA server. This enables us to make underlying (for example breaking) changes to the HTTP API while keeping the rego rules API stable.

The documentation will be updated to use the deployed rego rules once available.
About unencrypted HTTP

The User info fetcher serves endpoints over clear-text HTTP.

It is intended to only be accessed from the OPA Server via localhost and to not be exposed outside of the Pod.

 
package test (1)

# Define a function to lookup by username
userInfoByUsername(username) := http.send({
  "method": "POST",
  "url": "http://127.0.0.1:9476/user",
  "body": {"username": username}, (2)
  "headers": {"Content-Type": "application/json"},
  "raise_error": true
}).body

# Define a function to lookup by a stable identifier
userInfoById(id) := http.send({
  "method": "POST",
  "url": "http://127.0.0.1:9476/user",
  "body": {"id": id}, (3)
  "headers": {"Content-Type": "application/json"},
  "raise_error": true
}).body

currentUserInfoByUsername := userInfoByUsername(input.username)
currentUserInfoById := userInfoById(input.id)
1 The package name is important in the OPA URL used by the product.
2 Lookup by username
3 Lookup by id

For more information on the request and response payloads, see User info fetcher API

User info fetcher API

HTTP Post Requests must be sent to the /user endpoint with the following header set: Content-Type: application/json.

You can either lookup the user info by stable identifier:

{
  "id": "af07f12c-a2db-40a7-93e0-874537bdf3f5",
}

or by the username:

{
  "username": "alice",
}

If the user is found, the following response structure will be returned:

{
  "id": "af07f12c-a2db-40a7-93e0-874537bdf3f5",
  "username": "alice",
  "groups": [
    "/superset-admin"
  ],
  "customAttributes": {}
}