4 ms·

The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies impl

The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about LDAP. While I don’t have any experience using it, I wondered whether you could simply use LDAP to implement your access control. Someone on Stack Overflow asked the same question: https://stackoverflow.com/questions/3363267/ldap-for-application-access-control-how-much-should-it-control https://stackoverflow.com/questions/3363267/ldap-for-applica.... The accepted answer mentions that LDAP can be used for high-level access information, but that the lower level should be handled by the application, as the LDAP scheme would otherwise become complicated. Fair enough. My question is: What experience do others here have with implementing access control? Have you used LDAP? Is there another general tool built for this purpose which saves us the trouble of building our own system? Surely someone like IBM and Microsoft have built something for this. Are there any open source alternatives?

amaccuish 8y ago
Microsoft's architecture usually uses Kerberos Delegation, so access control is implemented in the backend. Say you've got an IIS web server, and SQL server; when the user logs into your application, they either delegate their tgt to the webserver or the web server gets a ticket on behalf of the user via Kerberos Protocol Transition (if they used a username and password in a form), the IIS server then authenticates to the backend, essentially impersonating the end user, so that the backend SQL server can look at it's own ACLs, rather than the web server having full access to the database and implementing its own ACLs. All this relies on having users in LDAP (specifically Active Directory). You could also go with what most people do, which is what is described in that article, in that you have groups as roles in LDAP, and simply lookup what groups a user belongs to, to determine access levels.
blakesterz 8y ago
There's Shibbeloth: https://www.shibboleth.net/ https://www.shibboleth.net/ Not as easy as LDAP, it's designed for bigger places, like Universities
- chrisswanda 8y ago
  And there's Shibboleet too. https://www.xkcd.com/806/ https://www.xkcd.com/806/
thexa4 8y ago
We've used LDAP for authentication by binding as the user and checking if they belong to certain groups. Those groups are then used to give the user certain abilities. https://github.com/debolk/bolklogin https://github.com/debolk/bolklogin User management was done through gosa / fusiondirectory.
nineteen999 8y ago
I've extensive use with LDAP over the last 20+ years or so. It's great for various authenticating various Linux/UNIX system bits and applications - in the past I've supported everything from Tacacs and Radius, Apache with LDAP auth, storing SSH public keys (both hosts and user keys), password expiration policies and even sudo rules stored in LDAP. There is a pretty steep learning curve though and there are many, many applications out there (particularly commercial ones) that claim to support LDAP but when you take a closer look their support is pretty broken and it can take a lot of effort to get everything working. LDAP also has some legacy warts, and competing/incompatible bits - for example LDAP-TLS vs the deprecated LDAPS, RFC2307 vs RFC2307bis schemas etc. Working with LDIF can be an utter pain sometimes (esp. with trailing whitespace) and the management tools outside of Active Directory leave a lot to be desired. It still beats the heck out of trying to synchronize tens/hundreds/thousands of user accounts with something like Puppet, which I've seen so many devops orgs do badly.

amaccuish 8y ago

Microsoft's architecture usually uses Kerberos Delegation, so access control is implemented in the backend. Say you've got an IIS web server, and SQL server; when the user logs into your application, they either delegate their tgt to the webserver or the web server gets a ticket on behalf of the user via Kerberos Protocol Transition (if they used a username and password in a form), the IIS server then authenticates to the backend, essentially impersonating the end user, so that the backend SQL server can look at it's own ACLs, rather than the web server having full access to the database and implementing its own ACLs. All this relies on having users in LDAP (specifically Active Directory). You could also go with what most people do, which is what is described in that article, in that you have groups as roles in LDAP, and simply lookup what groups a user belongs to, to determine access levels.

blakesterz 8y ago

There's Shibbeloth: https://www.shibboleth.net/ https://www.shibboleth.net/ Not as easy as LDAP, it's designed for bigger places, like Universities

chrisswanda 8y ago
And there's Shibboleet too. https://www.xkcd.com/806/ https://www.xkcd.com/806/

thexa4 8y ago

We've used LDAP for authentication by binding as the user and checking if they belong to certain groups. Those groups are then used to give the user certain abilities. https://github.com/debolk/bolklogin https://github.com/debolk/bolklogin User management was done through gosa / fusiondirectory.

nineteen999 8y ago

I've extensive use with LDAP over the last 20+ years or so. It's great for various authenticating various Linux/UNIX system bits and applications - in the past I've supported everything from Tacacs and Radius, Apache with LDAP auth, storing SSH public keys (both hosts and user keys), password expiration policies and even sudo rules stored in LDAP. There is a pretty steep learning curve though and there are many, many applications out there (particularly commercial ones) that claim to support LDAP but when you take a closer look their support is pretty broken and it can take a lot of effort to get everything working. LDAP also has some legacy warts, and competing/incompatible bits - for example LDAP-TLS vs the deprecated LDAPS, RFC2307 vs RFC2307bis schemas etc. Working with LDIF can be an utter pain sometimes (esp. with trailing whitespace) and the management tools outside of Active Directory leave a lot to be desired. It still beats the heck out of trying to synchronize tens/hundreds/thousands of user accounts with something like Puppet, which I've seen so many devops orgs do badly.