Open Stack

Hi Henry

this message is very helpful and I look forward to reading your BP when 
it is finished. Here are a few comments that might help you

1) Often the external corporate LDAP and the external IDP will be one 
and the same entity from the perspective of the token store/Get token 
method, and one query to one entity will return perform both functions 
and return both sets of information (as signed assertions) 
simultaneously. The combined query might be "authenticate this user and 
return me the set of roles/attributes this user has for my resource".

2) In general an external IDP/LDAP will not be able to provide the roles 
and projects for Keystone that the token store/Get token method needs, 
since organisational IDPs already store all the user attributes they 
need for internal purposes, prior to OpenStack coming into existence. 
The information is provided by HR and computer services staff, and 
organisations typically do not want to alter this data very frequently, 
or for some internal group of users who might have some temporary 
arrangement with some external service (such as an OpenStack cloud 
service). This problem has been known about for almost a decade, and so 
different mechanisms have been developed to cater for this this. In 
SAML, the Shibboleth software provides an attribute mapping function to 
map from internally stored (LDAP) attributes into a fixed standard set 
of attributes that are provided to the federation, often (though not 
necessarily) regardless of the SP they are being sent to. These are 
usually based on the EduPerson schema. This solution is not sufficient 
since it is not fine grained enough. In the grid world, VOMS servers 
have been developed to cater for this situation, by allowing VO 
administrators to assign the necessary roles to the various members of 
the VO, independently of the organisational IDPs. But this complicates 
things (it requires attribute aggregation) and requires groups to run 
separate VOMS servers. Thus diagram 3 as currently envisaged wont work 
in practice.

3) Who is driving the token module in diagrams 2 and 3? Is it the end 
user or another internal Keystone process? This is not clear.

4) I would therefore prefer diagram 3 to work as follows:
a) the get token module is called by another Keystone process that traps 
the user's API request and takes care of processing it (call this module 
A). It passes to the token module all the information it requires for it 
to generate a token. No external call out is needed. The token module is 
responsible for cryptographically producing a token from the input 
information. A sister module (Validate token) takes as input a 
cryptographic token and returns all the information encapsulated in it. 
The token module could work by storing all this information in an 
internal DB and simply returning a secret, or by packaging all the 
information into its token. But this is an implementation decision.
b) Module A sends a combined authentication and attribute request to the 
external IDP (or it could still be two separate messages, but going to 
one combined IDP entity as you cannot assume the IDP is running an LDAP 
server - it should be hidden to Keystone)
b) Module A does any other processing it needs (such as trust checking, 
attribute mapping etc) then calls the get token module.

I hope this is helpful

regards

David


On 03/06/2013 09:50, Henry Nash wrote:
> Hi David,
>
> So this question is relates exactly to the point I am at trying to
> re-write the auth-roleassignment-domain blue print.  Not yet complete,
> but here, as food for thought, are three new diagrams I am adding that
> try and show how we re-cast the current identity components ready for
> the mix of internal and external "providers" that we want to enable:
>
> First, the case for an all-internal solution:
>
>
> Second, what happens if we have external authentication only:
>
> ...and finally, potentially, for both auth and role assignment being
> external:
>
> The question I am trying to thinking through (and which relates to your
> question as well), is how much "internal support" remains for users/role
> assignments etc. as these functions are provided externally?  Do we need
> to still support "openstack only  users/roles"?  For example service
> users...a corporate LDAP/IDP might not contain these.  Also, might a
> cloud provider want a way of preventing a given user authenticating
> (what ever the external authority says).  Would you do this by a black
> list, or just allow the creation of an internal (to keystone) user
> entity that was disabled...and have internal user entities "override"
> the external permissions?
>
> Hope to have this nailed and included in the BP this week.
>
> Henry
> On 1 Jun 2013, at 10:31, David Chadwick wrote:
>
>> In various discussions that we have had about auto user provisioning
>> and token creation, it seems that there are at least three possible
>> design options as follows. The purpose of this email is to generate
>> discussion about the various options and agree on which one is the
>> best one to pursue for the Havana release.
>>
>> In the following discussion it is assumed that a user does not
>> initially have an entry in the Keystone database, and that the
>> authentication process has returned a session validity time for the user
>>
>> Option 1.
>> Create a temporary user entry (i.e. a normal entry with an additional
>> validity time field) with a validity time equal to the session
>> validity time), then use the existing token generation code to create
>> a token, with the proviso that the token validity time is not greater
>> than the entry validity time
>>
>> Option 2.
>> Create a permanent user entry, then use the existing token generation
>> code to create a token, with the proviso that the token validity time
>> is not greater than the session validity time
>>
>> Option 3.
>> Dont create a user entry. From the user information obtained from the
>> authentication and identification process, call the proposed new token
>> generation plugin to create a token with a validity time equal to the
>> session validity time. In this case, federated users will never have
>> entries in Keystone's database.
>>
>>
>> Pros
>> Option 1. A background process can easily decide when to delete
>> temporary entries, based on the dates of their validity fields.
>> Option 2. Does not need to change the existing user entries.
>> Option 3. Does not need to create or delete user entries.
>>
>> Cons
>> Option 1. Validity time needs to be updated each time the user logs in
>> Option 2. User database grows to infinity. No easy way of knowing
>> which entries have expired and which have not. May  need to add meta
>> data to Keystone entries such as date of creation, date of last access
>> etc. so that a background process can delete old entries
>> Option 3. Needs the token creation to be completely separate from user
>> entries and not to depend upon their existence. This is something
>> Guang is currently working on
>>
>> Let the discussion begin!
>>
>> regards
>>
>> David
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>