Skip to content

Document how BindAuthenticator fetches attributes #8725

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ghost opened this issue Jun 18, 2020 · 1 comment
Open

Document how BindAuthenticator fetches attributes #8725

ghost opened this issue Jun 18, 2020 · 1 comment
Labels
in: docs An issue in Documentation or samples type: enhancement A general enhancement

Comments

@ghost
Copy link

ghost commented Jun 18, 2020

As requested, I am splitting the long and unclear #8560 into several issues. This issue is about documenting how BindAuthenticator fetches attributes.

Behaviour

There are two ways to use BindAuthenticator. Way one: call setUserDnPatterns. Way two: call setUserSearch.

If you choose the first way, BindAuthenticator will attempt to bind with the dnPatterns you gave it. It will not, as far as I can tell, perform any search. If the bind succeeds, it will fetch the user's attributes with the user's permissions.

If you choose the second way, BindAuthenticator will perform a search for the user with the app user's permissions. Probably, this search will fetch some attributes -- again, with the app user's permissions. Then, it will bind as the user -- but it will not fetch attributes again.

In summary: if you choose the first way, you get all of the user's attributes that the user can see. If you choose the second way, you get all of the user's attributes that the app user can see. In some LDAP configurations, those two things are not the same.

To see this in action, go to this repository and follow the README. Having done that, first check out one of the only-dnpatterns-* branches. Log in and observe that you can see (in the logs) the sn attribute. Then, check out one of the only-search-* branches. Log in and observe that you can't see the sn attribute. (The access controls of the server are configured so that the user can read the sn attribute, but the anonymous user -- which the application binds as -- can't.)

Why this merits documentation

I spent a couple of hours trying to figure out why changing my bind strategy changed which attributes got fetched. I don't think I'm unusual in not expecting that to happen. It's worth thinking about not making it happen, but that's a separate issue (#8727); whether or not you decide to change the API, documenting the current behaviour seems sensible.

Where to document it

Here, or in the section immediately after ("Using Bind Authentication"). I think just adding the information in my "in summary" paragraph from above is enough.

@rwinch
Copy link
Member

rwinch commented Jun 19, 2020

The suggested location sounds good to me. We can always refactor things as needed.

@rwinch rwinch added in: docs An issue in Documentation or samples and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: docs An issue in Documentation or samples type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant