On Tue, Jul 02, 2013 at 12:58:06PM +0100, Ian Duffy wrote: > tldr: should ldap passwords be cached within cloudstack? > > Hi Guys, > > I wanted to get your opinion on something. I seen a JIRA ticket for > adding support for multiple LDAP because if the single LDAP server > fails you lose access to your Cloudstack console. I plan to add > support for multiple ldap servers. But I've been wondering why not > cache passwords on cloudstack too? > > So from what I understand when a user logs in their password is passed > down through all the user authenticators(I'm open to correction on > this) until it finds one that passes otherwise login fails. It > wouldn't be too difficult to utilize this implementation to support > caching of ldap passwords within cloudstack. I'll explain by example. > > We have the following user account: > Account name: user1 > Password set in cloudstack: cspass > Password set in ldap: ldappass > > When user1 attempts to login with password cspass it hits the > cloudstack database and returns true and is successfully logged in. > When user 1 attempts to login with password ldappass it hits the > cloudstack database, fails tries against ldap successes and > successfully logs in. > > My suggestion is to take their password on a successful login and > place it into the cloudstack database so in the event all LDAP servers > went down the user would be able to authenticate against the > cloudstack database. > > Of course this has security issues.... one that comes to mind, if a > users ldap account becomes compromised and they need to change their > ldap password their old password will still work for cloudstack logins > until they login to cloudstack using the new one. >
To me, the main reason for an LDAP authenticator is so that an organization can utilize a central identity system for it's security controls. Anytime an app does a "cache" of credentials, my $dayjob tries to figure out how to disable the cache and / or set it's TTL as low as possible. The reason for this is that the revocation of rights is expected to be executed as quickly as possible (even going so far as to require that custom apps have the ability to invalidate any active sessions for a user that is disabled / deleted). Now... looking at CloudStack specifically, it's actually quite a mess of different / conflicting configurations for identity and ACLs. A user should probably be tied to a specific authenticator (IMO only), so that there isn't a backdoor option for getting them into the system. Also, we have the problem of the API keys. Any user that has API keys can effectively keep using the system after an LDAP admin has disabled their account. That's not particularly good. So I think that I'm at least against this being implemented without a TTL and / or config flag to disable the cache mechanism. If I can disable it, then I don't mind if it's cached. Consider the rest of my commentary as just simply complaining without offering a solution. ;-) That all being said, it's great to see you thinking about improvements that may be greater in scope than the actual GSOC project! -chip
