> 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.
This is an issue I have come across too. With the way the authenticators are implemented it would be very easy for a user to keep their account despite it being removed/disabled in <insert-some-external-authentication-service-here>. A user just has to change their CS password to grant themselves access that can only be revoked by a cloudstack admin. On 2 July 2013 14:14, Chip Childers <chip.child...@sungard.com> wrote: > 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
