Host-based Access Control
Short description
I would like to offer users the ability to allow access to pages from outside our intranet. I envisage something like {{{#acl .example.com:read 192.168.2.0/24:read,write }}}
At the moment, of course, one can achieve something similar to this with Apache mod_access directives (Allow from), but this is a little too coarse-grained for users.
Our wiki is used as an intranet and some of the contents would not be appropriate for public consumption. However certain collaborations require making available information to colleagues at other institutions, and allowing them to contribute to the wiki.
What's the problem with user based access control? I thought host based stuff is rather outdated since those days of NFS being invented.
- The problem with user based access control in this case is that there is a class of user, normally someone that doesn't need to edit the wiki often (e.g. a manager type), that will not create/remember another user account. It would be extremely useful to have host based ACLs in this case.
that sounds like a dir directive in the web server configuration
- The problem with user based access control in this case is that there is a class of user, normally someone that doesn't need to edit the wiki often (e.g. a manager type), that will not create/remember another user account. It would be extremely useful to have host based ACLs in this case.
As "'", "@", "." are legal within usernames the upper solution does not work. A solution should also avoid ":" and "," as they are used within acls. I'd suggest to append "/" to the domain names and check for a containing "/" as "/" is illegal in usernames. You could then modify MoinMoin.wikiacl.AccessControlList to check for these entries (after the groups because groups can contain "/"). May be using another char at the beginning is even better.
What's about that you can add users and/or ip-adresses to a Group. Like ManagerGroup containts then some Users and IP-Adresses. Well on the otherside it would mix edit from user acounts and edit from allowed hosts (hmm... sorry but my idea sounds terrible; please next one...). So it would be maybe easier to asign a pre-defined user account to some ip-adress. So it would be more an autologin features based on the host ip adresses or ranges (for a generaly user like IntraNet). also for intranet use maybe you could use some ADS or LDAP authentification (even a manager need at some point to authenticate himself, even he's god like
). Generely I do not like some config stuff in the apache httpd.conf. What's happen if you use a TwistedServer or even a LightHTTP, better to let MoinMoin handle the Auth stuff! Well just my 5cents -- MarcelHäfner 2007-11-13 12:02:41
Host-based (IP-based) authentication / access control was one of the worst ideas in computer history, so I don't think we should implement that.
Just imagine that you give IP 1.2.3.4 access to something because this is the fixed IP of the boss' machine. The problem is that this IP might be well-known to be the boss machine's IP and so everybody else in the LAN could just configure this IP on his machine (when the boss' machine is off or unplugged) and do stuff that later will look like the boss would've done them.
Also, machine != user, there can be multiple users on the same machine.
There might be some good uses of IP-based stuff (e.g. if there is no other way, e.g. for blocking some attacker from the internet), but usage in ACLs and related stuff would make more problems than it's worth.
-- ThomasWaldmann 2007-11-13 13:02:06
well, your right! sure i'm also looking for easier way for user-logins. it's just stupid to use so many different logins (user/password) for every application. in our office I'll try to "integrate" MoinMoin with Active Directoy, bye. -- MarcelHäfner 2007-11-13 13:20:23
- Obviously host based authentication is not secure, however it is still useful for a number of applications. It is up to the user to use it properly and the default configuration could not allow it. We would use it to temporarily give specific users outside of our institute read access to a private page. This turns out to be quite useful for collaborations where the user needs temporary or quick access and thus doesn't want to have to create a whole user account.
Gary Bader 2007-11-20 23:16:34
The auth part can be easily done with the new auth system, and the host part could also be implemented there by making an auth method that always logs those hosts in ... Reject because we won't implement this but it is doable without any core changes. -- JohannesBerg 2008-03-18 01:13:06