BookStackApp / BookStack

A platform to create documentation/wiki content built with PHP & Laravel
https://www.bookstackapp.com/
MIT License
15.47k stars 1.94k forks source link

Expose the Ability To Set External Authentication IDs for OIDC Group Mappings via Config #5081

Closed joelmccoy closed 5 months ago

joelmccoy commented 5 months ago

Describe the feature you'd like

I would like to be able to set the group mappings for the default roles via an Environment Variable or some other configuration setting. Currently it appears you can only set this in the Admin GUI.

Context: I am using KeyCloak for OIDC auth with Bookstack. The group claims are being passed over as the full path of the group in KeyCloak. So if I create an Admin group in KeyCloak this is passed over in the claim as /Admin. This makes it very hard to match group names to the default roles.

It appears you can only create the mapping of /Admin -> Admin in the GUI admin console which is unideal.

This means I would need to:

  1. Set the auth to Standard Auth and deploy the app
  2. Login into the Admin Console with the Admin user set these mappings manually
  3. Redeploy the app with the auth set to OIDC

Describe the benefits this would bring to existing BookStack users

Ideally, if we could just pass these mappings in as configuration values (i.e. OIDC Group Name -> Bookstack role) it would remove the need for manual steps highlighted above. And I wouldn't need to deploy the app with Standard Auth first.

Can the goal of this request already be achieved via other means?

Not that I am aware of.

Have you searched for an existing open/closed issue?

How long have you been using BookStack?

Not using yet, just scoping

Additional context

No response

ssddanbrown commented 5 months ago

Thanks for the suggestion @joelmccoy, but I don't really assure, our want to increase our scope, to allow all UI actions/options to be handled via config options where there's a minor edge-case or desire to suit.

As another (albeit non-supported) option would be to run some update statements against the database after creation to set the desired ID mapping.

joelmccoy commented 5 months ago

Understandable. But, I'm also surprised that many other people aren't running into this issue. Running this app in a production environment configured with federated identity is not possible just with configuration files. It requires some manual intervention no matter what (or some hacky work around to make updates to the database).

Many open source apps that support OIDC allow for group matching as a configuration. Grafana for example allows expressive language to match groups to roles in a configuration setting.

This makes this app unadoptable in our environment without some hacky work around. All the other we apps we use integrate nicely with group/role matching. I understand this may be an edge case and not warrant a priority feature. Just wanted to add some context to my particular use case.

ssddanbrown commented 5 months ago

Thanks for your understanding, I'll therefore close this off as out of scope.

As an extra option that I've since thought of, it could be possible to use the logical theme system to listen to OIDC_ID_TOKEN_PRE_VALIDATE events and manipulate the OIDC provided role names to match/map as desired on entry/login events (which you could then link to a config file/format if desired).