Re: [id-cloud] Comments on Identity in the Cloud PaaS Profile,Version 1.0

[David Chadwick <d.w.chadwick@kent.ac.uk>]

On 16/05/2013 16:55, Anil Saldhana wrote:
> On 05/15/2013 06:27 AM, David Chadwick wrote:
> > Dear list
> >
> > here are my comments on this doc. Having implemented federated
> > identity management in OpenStack, we have some experience of this topic.
> >
> > 1. The Authentication Services should be renamed Identification and
> > Authentication Services with a revised definition, thus:
> >
> > are responsible for identifying and authenticating users to PaaS
> > applications. Identification and authentication Services need to take
> > into consideration that the authenticated identity may be a federated
> > identity, and that these services may be provided by federated
> > identity providers.
> >
> > 2. Use Case 26. Identity impersonation.
> > We should have no recognition or support for this feature.
> > Impersonation is bad. full stop (since you cannot tell the difference
> > between the real entity and an impersonator - they are the same as far
> > as the system is concerned). What you want is delegation, so that they
> > have the same Authz rights, but have different authenticated
> > identities. Then you can do a proper audit. So strike out identity
> > impersonation.
>
> David - the usecase is when cloud support team wants to debug issues, an
> user is facing with the PaaS.  I am unsure delegation works for this use
> case.

If the problem is related to authn, then it could mean that the admin 
team will need to know the user's pw or other credential in order to see 
what is going wrong. Which is a bad thing. (Why cant they look at the 
logs to find out?)

If the problem is related to authz, then there is no requirement for 
impersonation, all the admin team need to have is the same set of authz 
attributes as the user, in order to get the same set of privileges. If 
the system uses UserID as the only authz attribute (stone age system I 
know, but they still exist), then some system component has to assert 
this UserID to another component (probably the authn service). So this 
component needs to be modified to allow an admin to login, and assert 
any user ID that it needs for authz for the session. Now you dont have 
masquerade, since the logs will show that the actual user is an 
administrator.

regards

David
> > 3. There are other challenges for section 4. Namely
> >
> > A. Trust management
> > The trust that a cloud service has in the identification,
> > authentication and authorisation capabilities of a federated identity
> > provider need to be managed and controlled
> >
> > B. Identity Mapping
> > There is a need to be able to map between the identity asserted by a
> > federated identity provider and the authorised identity(ies)
> > recognised by the cloud applications.
> >
> > C. 4.2 should be renamed User Provisioning
> >
> > regards
> >
> > David
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php