how to enable document level access control without enabling the login mentioned in this repo?

[thwayant]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Any log messages given by the failure

Expected/desired behavior

We have a application which is build from an older version of this exact rep, and only members of a specific AD group can access that application, when any person goes to the URL of the application, the person is re-directed to microsoft's login page, where the person login with the company provided email and password, and if the person is part of the AD group he/she is redirected to the application. We are looking into having document level access control so that some user from the AD group have access to only some document and not all, is this possible with the document level access control mention here, if yes then how and if no then is there another guide which i can follow. Thanks

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

azd version?

run azd version and copy paste here.

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

[thwayant]

To elaborate further, currently even if a person A is a part of the company and has company's provided email, if he is not in the specific AD group, he cannot access the application, what I want to do is restrict responses for user to specific documents only, so when person B asks a question he get reply based on only 4-5 specific documents only and not all the document in the index, also the build used is before vectors were implemented. updating to the latest code from this repo is not possible due to internal reasons, thanks.

[pamelafox]

You say you can't update to latest code, but presumably you expect to make some sort of code change for this scenario, so hopefully you have the possibility of at least copying over some new code. One thing you could do that might be a smaller change than associating ACLs with each document is to use two separate indices, one for A and one for D, and change the code to use that index based off the group claims for the logged in user. You would need to inspect the group claims in the Python code to decide that, and you could use similar logic to what's currently in the codebase.

Also, I know you said you can't update to the latest changes from @mattmsft, but his blog post may still be helpful in giving ideas for how to do group restrictions:
https://techcommunity.microsoft.com/t5/azure-ai-services-blog/access-control-in-generative-ai-applications-with-azure/ba-p/3956408

[thwayant]

Hi @pamelafox, thanks for the reply, I'm only authorized to make code changes which are directly related to implementing document level access control, making any other change is outside the scope of my authority. I'll check the blog to get a better understand of acls.

Thank You.

[mattgotteiner]

You should be able to use the ACL strategy defined in the blog. You can also copy over most of the integration code to your local fork as it's not requiring vectors.

[thwayant]

Hi @mattmsft, thank you for replying, we are using only one AD group, and only members of that AD group can access that application, do i need to create another AD group, or is one AD group fine for this purpose?, Also for auth we are using OAuth 2.0 auth code (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow) Thank you.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this issue will be closed.

[pamelafox]

Thanks for the question, and apologies for the delay. Document-level ACLs rely on user identity; without a login/identity source there’s no way to enforce per-user or per-group filters. You can use any trusted auth that provides oid/group claims (e.g., App Service built-in auth) instead of this repo’s login. A single AD group is fine to gate access, but for per-document trimming you’ll need to assign per-document oids/groups in the index and have the backend add the corresponding filters. A lighter-weight alternative is separate indexes per group.

If you’re on an older fork, the minimal pieces to backport are: oids/groups fields in the index, populate them (scripts/manageacl.py or the ADLS Gen2 path in prepdocs), and enforce filters in queries (app/backend/core/authentication.py). See docs/login_and_acl.md for details.

I’m going to close this as stale. If you still need help, please open a new issue with your auth setup, repo version, and what you’ve tried.