OpenCTI-Platform / opencti

Open Cyber Threat Intelligence Platform
https://opencti.io
Other
5.22k stars 822 forks source link

OpenID group mapping changes do not take hold when OpenCTI is restarted #3633

Open GraemeMeyerGT opened 1 year ago

GraemeMeyerGT commented 1 year ago

Description

Environment

  1. OS (where OpenCTI server runs): Ubuntu 22 LTS running Docker
  2. OpenCTI version: 5.8.7

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Use the PROVIDERS__OPENID__CONFIG__GROUPS_MANAGEMENT__GROUPS_MAPPING variable in docker compose config to map an OIDC group to a group in OpenCTI (e.g. "threat intelligence analyst" group)
  2. Boot the system
  3. Put your user account into the group
  4. Confirm it has the mapped group (e.g. "threat intelligence analyst")
  5. Change the mapped group in the docker compose config to a different group (e.g. "administrator")
  6. Restart the OpenCTI container (docker restart opencti-opencti-1)
  7. Log back into OpenCTI interface
  8. Observe that the group your user account is in has not changed.

Expected Output

I would expect restarting the application to immediately cause RBAC changes to take effect.

Actual Output

My group changes are not immediately taking effect, and persist for quite some time (minutes or hours). It seems likely to me that the user session is still alive with the OIDC provider (in our case, Okta), and that that is somehow causing OpenCTI to persist the original configuration over a restart, despite the changes.

Additional information

The overrides section of our config:

version: '3'
services:
  opencti:
    environment:
      - APP__SESSION_TIMEOUT=14400000
      - APP__REQUEST_TIMEOUT=14400000
      - PROVIDERS__OPENID__STRATEGY=OpenIDConnectStrategy 
      - "PROVIDERS__OPENID__CONFIG__LABEL=Login with Okta"
      - PROVIDERS__OPENID__CONFIG__ISSUER=${OKTA_OIDC_ISSUER_URL}
      - PROVIDERS__OPENID__CONFIG__CLIENT_ID=${OKTA_OIDC_CLIENT_ID}
      - PROVIDERS__OPENID__CONFIG__CLIENT_SECRET=${OKTA_OIDC_CLIENT_SECRET}
      - "PROVIDERS__OPENID__CONFIG__REDIRECT_URIS=[\"${OPENCTI_BASE_URL}/auth/oic/callback\"]"
      - "PROVIDERS__OPENID__CONFIG__GROUPS_MANAGEMENT__TOKEN_REFERENCE=id_token"
      - "PROVIDERS__OPENID__CONFIG__GROUPS_MANAGEMENT__GROUPS_SCOPE=groups"
      - "PROVIDERS__OPENID__CONFIG__GROUPS_MANAGEMENT__GROUPS_PATH=[\"groups\", \"realm_access.groups\", \"resource_access.account.groups\"]"
      - "PROVIDERS__OPENID__CONFIG__GROUPS_MANAGEMENT__GROUPS_MAPPING=${OPENCTI_GROUP_MAPPINGS}"
      - "PROVIDERS__OPENID__CONFIG__ORGANIZATIONS_DEFAULT=[\"Our Organization\"]"

Yes we have long session and request timeout values set - this is due to troubleshooting some problems with too-short user sessions. I would nonetheless expect changes to the RBAC group mapping and a system restart to override that.

richard-julien commented 1 year ago

When you say Log back into OpenCTI interface you talk about a logout/login or just refreshing the browser on an exiting session?

GraemeMeyerGT commented 1 year ago

I've tried both. Clicking the opencti logout button does send you back to the login screen, but I think I recall one of the devs before saying it may not terminate the login session with the OIDC provider. It certainly doesn't log you out of Okta. Could explain why the session persists

richard-julien commented 1 year ago

Just tested the logout/login oidc without problem with our keycloack, groups are correctly rebind at login. If you dont use the logout we currently doesnt rebind the user on the fly, its only done at login phase.

GraemeMeyerGT commented 1 year ago

Okay that would make some sense - but does OpenCTI support logout for OID providers? How can it be implemented?

richard-julien commented 1 year ago

It could be implemented yes but not sure why it will solved your problem.

GraemeMeyerGT commented 1 year ago

You're right I suppose, it wouldn't resolve this issue. Perhaps the platform should rebind login groups when boot?

richard-julien commented 1 year ago

Its not possible to rebind when booting, we dont have any concept of SSO provisioning. I think for this kind of situation after booting we need to go to administration and kill all user sessions. This way your users will be forced to login again and so will be rebind.

GraemeMeyerGT commented 1 year ago

That seems reasonable. It should enable admins to force an update of RBAC changes which will be useful