Support permissions for models (and possibly tools/assistants)

[zacps]

Describe your feature request

We are considering using chat-ui for our own custom LLM tools. Because we want complete control over the generation we're currently implementing these as models. However, some of these tools will have access to documents that are not broadly available within the company. Because of this we want to be able to restrict model access by user.

Implementation idea

• Retrieve groups via OIDC
• Add an alllowed_groups field to each model
• Restrict usage & visibility of each model by group membership

We're currently working on implementing this in our private fork, but I wanted to reach out to ask @nsarrazin if a patch would be accepted upstream, and if there would be any additional requirements.

[nsarrazin]

I think that would be a great addition! We would definitely accept a patch for this as long as it's not a breaking change, which should be doable 😄

[moellert]

This is currently my biggest question mark for using assistants to implement our RAG, as not all data should be accessible by everyone. I'm not a developer, but I'd be happy to help with testing when the time comes!

[nsarrazin]

Yes I think it would be a great add, however it's not really aligned so far with the chat-ui features we use for HuggingChat so we're not really dedicating much internal resources on this.

However I would happily discuss an implementation plan for this with someone who feels like making a PR for it!

[moellert]

@zacps how far have you come with your implementation?

[jonstrutz11]

Hi all! While Zac opened this issue here, I'm the one who led this specific effort internally at our company (with much help from @zacps).

To update y'all, we do have a working solution at this point on our private fork of chat-ui. We abstracted away the specific auth provider and use a hybrid flow (response_type=code id_token) to authenticate if this feature is turned on in the config, use the id token to get an access token, grab a user's groups (using MS Graph API in our case) using the access token, and then show/hide models based on those groups. We implemented it with microsoft Entra as an auth provider, but like I said, we abstracted these details away (similar to how "endpoints" are handled) so that folks could implement this functionality for other auth providers reasonably easily.

There are some other features we added to our private fork as well, but I'm not sure how much about those I can say here or if we plan on upstreaming them (@zacps feel free to chime in, although for everyone's benefit Zac is on vacation for the next 2 weeks so may take some time to respond).

I plan to rebase our private fork onto the current upstream branch and then submit a PR with Zac's help once he returns from vacation in 2-3 weeks (I anticipate there will be quite a few merge conflicts).

[nsarrazin]

Hi :wave: Let me know once you have a PR and I'll happily help with merge conflicts and such :smile: