Open Stack

I'd be more interested in the impact of not providing a user ID in the
authentication response at all, but instead having a privileged call in
keystone to *attempt* to lookup the user associated with a token, if one
exists.

Swift wouldn't be able to define ACL's by user_id, our 3-step
authentication flow would have to change (GET /users/{user_id}/projects
wouldn't be viable for users that don't know their own user_id)... can't
think of anything else...


-Dolph


On Thu, Jan 31, 2013 at 12:33 PM, Adam Young <ayoung at redhat.com> wrote:

> 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<OpenStack-dev at lists.openstack.org>
>>>>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.**org<OpenStack-dev at lists.openstack.org>
>>>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>>>
>>>>
>>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130131/ed76a59b/attachment.html>