Open Stack

On 01/31/2013 10:40 AM, David Chadwick wrote:
> this is missing the whole point of federation and ABAC. We do not want 
> to base access on unique IDs (or the lack of them) but rather on the 
> identity attributes that users posses. Your proposal would only work 
> if all users from the same IDP had the same set of identity 
> attributes. But this is obviously not the case.


Nope.


WHat matters is what is in the token.  The User ID is just a 
book-keeping tool in this case.

>
> As I said in a previous posting, a new way of thinking about authz is 
> needed, one that is not based on the unique user IDs that Keystone 
> assigns.

Think of it his way.  If i invite you to the Open Stack table via 
Federation, I am responsible for you.  The common userID is the account 
responsible for the actions of the ephemeral users.

The token will have a set of identity attributes in it, signed by 
Keystone.  That is all the user needs, not a separate account in 
Keystone's user table.

Another way of saying it is that we already have an ephemeral user 
construct, it is the token.

>
> For a start, when you first configure your federated OpenStack system, 
> there wont be any users in the database and so there wont be any 
> unique Keystone user IDs, so services wont be able to create ACLs 
> based on them.
Not true.  There are mechanisms for pre-populateing the users, part of 
the install system.  You don't need to completely pull yourself up by 
your own bootstraps.
>
> However, the users *do* exist, and they do have identity attributes 
> that will be asserted by the IDPs. So the services *can* build their 
> access controls at initialisation time, before any users are created 
> in Keystone (I am only taking about end users not admin users which 
> will exist). The services do this by deciding which keystone 
> attributes (project, roles etc) they will give the users in exchange 
> for their IDP asserted attributes via the new attribute mapping 
> service we have built.
>
> So when a user does log in, via his IDP, a temporary user entry in 
> Keystone is created for the session, his IDP attributes are mapped 
> into the correct set of roles and projects (tenants), and the service 
> gives the user the correct set of access rights. When the session is 
> completed, the user entry will be automatically deleted from Keystone.
>
> Its clean and simple. Kristy is already building this
>
> regards
>
> David
>
>
> On 31/01/2013 15:29, Adam Young wrote:
>> Create a user per federated source. Federated users with no unique IDs
>> are associated with the common user account.  That account should be
>> able to access the set of all resources that anyone in the account can
>> have.  It should not have a password, and users should not be able to
>> log in as that Federated user account.
>>
>>
>> On 01/29/2013 07:41 AM, David Chadwick wrote:
>>> Hi Adam
>>>
>>> I have addressed auditability in my previous post. Misuse can still be
>>> addressed even with transient IDs and transient users, so no further
>>> comments here on that issue.
>>>
>>> In our initial implementation of FIM we did indeed create new users in
>>> Keystone for every new user arriving from an IDP. This has two
>>> negative consequences
>>>
>>> a) we cannot deal with users with transient IDs (as can be produced by
>>> Shibboleth) so we have to mandate that permanent IDs are used by all
>>> IDPs (which Shibboleth can do). Still its a (minor) limitation.
>>>
>>> b) we have a housekeeping problem of knowing when to delete old users
>>> from the user database. In our initial implementation we did not
>>> address this, so the database just keeps on growing unless manual
>>> intervention takes place. This is a tricky problem to solve. When
>>> should an entry be deleted? Time limits is not an adequate solution.
>>> My account at Kent has been active for 8 years and growing, whereas
>>> students accounts are deleted each year. Should the IDP notify
>>> Keystone every time its database is updated? Or something else?
>>>
>>> So we thought that a better option would be to only hold transient
>>> user entries in Keystone for the duration of the validity time of the
>>> identity assertion from the IdP. This solves the user management
>>> problem, as well as the rights revocation problem, since a user now
>>> only has rights for the duration of his session. (If you want active
>>> revocation in the middle of a session this is a different issue.) User
>>> management is pushed right back to the IDP, which is the right place
>>> for it. The IDP keeps its user database up to date, and only current
>>> users will be given credentials to access Keystone.
>>>
>>> As far as I can tell the only negative consequence is on a service
>>> which currently uses the user ID in its access control list. Since
>>> Keystone creates this ID automatically when a user entry is created,
>>> then the same user will have different ID for different sessions. So
>>> the user ID ACL system wont work without either
>>>
>>> a) Federated Keystone having a different way of assigning unique IDs
>>> to user entries, so that the IDs can be the same for the same user
>>> even if the entry is deleted then created again, or
>>> b) services using a different attribute type in their ACLs (one that
>>> still contains a permanent unique ID for the user).
>>>
>>> regards
>>>
>>> David
>>>
>>>
>>> On 28/01/2013 17:50, Adam Young wrote:
>>>> On 01/28/2013 08:20 AM, K.W.S.Siu wrote:
>>>>> Hello,
>>>>>
>>>>> When Federated Identity Management is used, the authentication
>>>>> statement issued by the external Identity Provider(s) may contain a
>>>>> temporary (or transient) identifier for the user rather than a
>>>>> permanent (or persistent) one. Because of this, it is not possible to
>>>>> always uniquely identify the user each time when federated
>>>>> authentication is used in Keystone (unless one of the user's identity
>>>>> attributes is globally unique, such as an email address). As an
>>>>> existing user is required to issue tokens, it is necessary to 
>>>>> create a
>>>>> new user each time authentication takes place which could result in
>>>>> the backend storage becoming full of redundant data. As a solution to
>>>>> this, we propose the addition of a validity time field in the user
>>>>> entity which can be used to remove expired user data and allow
>>>>> temporary users to be created based on the ID provided by the 
>>>>> Identity
>>>>> Provider. Determining the details of the new user account will be 
>>>>> done
>>>>> by the proposed attribute mapping service.
>>>>
>>>> That is a pretty important distinction.  It would potentially have
>>>> impacts on Auditability.  Once you say the user object is 
>>>> transient, it
>>>> n longer has an authority to address misuse, at which point it falls
>>>> back on the organization that is Federated to Keystone. Would it be a
>>>> cleaner solution to link the tokens with a single federated 
>>>> account, and
>>>> then to use that account to create all tokens?  The tokens could 
>>>> have a
>>>> subset of roles and access to a subset of endpoints based on the data
>>>> approved by the Federated organization.  It would just be a metter of
>>>> nailing down how the ephemera ids are issued.  I would almost want 
>>>> them
>>>> to be stored in a separate table from the users, which is what the 
>>>> token
>>>> table already is.
>>>> Is it essential that we modify the user object, or are you just
>>>> proposing it as a "path of least resistance?"
>>>>
>>>>>
>>>>> At the moment we are wondering how people feel about this, and if
>>>>> anyone has any comments or suggestions.
>>>>>
>>>>> Many thanks,
>>>>> Kristy
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> 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
>>