On Jul 2, 2013, at 9:46 AM, Ian Duffy <i...@ianduffy.ie> wrote: >> 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. >
This is why you have things like shibboleth [1] and Oauth2 [2]. [1] http://en.wikipedia.org/wiki/Shibboleth_(Internet2) [2] not the main url, but interesting as it relates to LDAP CloudStack is a service provider and theoretically should not keep any user passwords Would be nice to have some Authn/Authz experts chime in ? -sebastien > 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
