cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Duffy <...@ianduffy.ie>
Subject Re: [DISCUSS] [GSoC] Caching of password on Cloudstack side
Date Tue, 02 Jul 2013 13:46:55 GMT
> 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.childers@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

Mime
View raw message