Skip to content
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

Feature request: add filter who is allowed to use DokuWiki #127

Open
igittigitt opened this issue Apr 11, 2022 · 4 comments
Open

Feature request: add filter who is allowed to use DokuWiki #127

igittigitt opened this issue Apr 11, 2022 · 4 comments

Comments

@igittigitt
Copy link

This may be only a special requirement for those running their own IAM, but especially there it is most needed.
If a user has authenticated through an IAM he will end up in DokuWiki with an user created and maybe some access (depends on the setup). For companies this is bad, as they need to control which one uses which application (e.g. DokuWiki).

Therefore i hacked the plugin to only successfully login a user if his groups (added a "group" claim to the oidc-client DokuWiki uses) contain a special usage-group (i've called it "DokuWiki_Users") in the IdP-payload. If this group-membership is not found, i add an errormessage telling the user that he is not entitled to use this service.

I'm really looking forward to have this incorporated into the plugin itself, even if using it in companies is just an edge-case.

What i've done with groups may also be done with roles from the IAM, or some other attribute in the payload of the IdP. So it might be wise to make this widely configureable. This is why i used "filter" in my request instead of "group-membership".

Very important in my opinion would be to have a custom action for the case a user does not match the requirement, e.g. simply show a page whith an custom message coming from a DokuWiki-page source. For me it seems important that this errormessage only shows the pages content and not the whole framework of DokuWiki. Another custom action could be to redirect to an URL instead.

@glensc
Copy link
Contributor

glensc commented Apr 20, 2023

@igittigitt why don't you share your code as pull request then?

@systemofapwne
Copy link

I am also interested in this feature for the very same case.

@systemofapwne
Copy link

Some more notes and considerations down here:
Even though I think, that there should be some kind of way to filter for registration/login of users according to their scopes (oAuth/OIDC rely on the oAuth client to do permission verification), one can still use the ACLs of DokuWiki to strip down access to the wiki.
Right now, everyone who can auth against our institutes (local) oAuth IdP, can log in to our wiki but ACLs will restrict permissions according to the "groups" attribute in the auth token.
Pro: It just works
Con: Users get added to the users.auth.php database, even when they won't get access granted according to the ACLs.

I fear, that there is no way to satisfy every condition because:

  • If you have a local IdP, you control the content of the token. Just set the 'groups' attribute and use ACLs to restrict access.
  • If you use external IdPs, chances are high, that you do not control the 'groups' attribute or anything at all. Worst case would be, when the external IdP sets the ''groups'' attribute such, that a person will be put into an admin group, thus escalating permissions (if overwrite groups is set).

@loelkes
Copy link

loelkes commented Aug 28, 2023

I'm in that situation and solved it by removing all permissions using ACLs from @ALL. User access is solved individual groups provided by the IdP. People lacking the groups are shown an error message that they don't have access. No surprises.

@systemofapwne You should at least be able to control the IdP or the DokuWiki ACLs. So you either add the matching groups or match them in the ACLs. @igittigitt could just the ACLs for the DokuWiki_Users without the need for a plugin modification. What do I miss here?

Apart from having the users in the local user database I don't see any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants