Open Stack

Hi Adam

looks like we are getting close to agreeing

On 01/02/2013 02:22, Adam Young wrote:
> On 01/31/2013 05:08 PM, David Chadwick wrote:
>>
>>
>> On 31/01/2013 18:33, Adam Young 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.
>> No sure what the nope was to.
> "Your proposal would only work if all users from the same IDP had the
> same set of identity
> attributes. "
> Nope.  It would work if the deployed policy were more fine grained than
> it is.  But they should not all have the same attributes.  I am assuming
> that your mapping mechanism has transformed  the attributes from the IDP
> into the roles (the cannonical form) that will be presented in a token.

Yes this is true. Even the same user does not need to present the same 
set of identity attributes in different sessions. So the privileges 
(roles, projects etc) will need to be dynamically set for each session 
through role mapping, whether the user has a permanent entry in Keystone 
or not. There thus seems to be little point in "reusing" an existing 
entry for any user. We may as well create a transient entry for each 
user each time they start a new session. This would also allow the same 
user to have two parallel sessions with different identities associated 
with each e.g. log in as admin and as manager in separate parallel sessions.

>
>>
>>>
>>>
>>> WHat matters is what is in the token.  The User ID is just a
>>> book-keeping tool in this case.
>>
>> Agreed. It is clear that what matters to the CSP is what is in the
>> token (if it validates the token) or what Keystone says is in the
>> token (if it asks Keystone to validate it), and not what Keystone
>> stores in its databases, since the CSP does not access the databases.
>>
>> In order for the token system to work, Keystone does not need a
>> persistent entry in its user database. It only needs a transient entry
>> which can be deleted after the user's session has completed. The book
>> keeping can cease once the user has finished using the CSP. The audit
>> trail remains in perpetuity, even if the user's account in Keystone
>> has been deleted.
>>
>>>
>>>>
>>>> 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.
>>
>> By "I" I assume you mean the OpenStack/Keystone administrator, so I
>> agree with this. However, in a federated system, the
>> OpenStack/Keystone administrator trusts the federation IDPs to
>> administer the user accounts, databases and user authentication
>> tokens, so that he does not have to. This is the whole point of
>> federation. In a federation, the SP trusts the IDP to manage the user
>> accounts so that it does not have to. Which is actually what OpenStack
>> currently supports in that the CSPs trust Keystone to do the user
>> account management. We are simply extending the existing trust model
>> into a federated environment so that the CSP trusts Keystone and
>> Keystone trusts the federated IDPs. Thus there is no point in
>> replicating the users accounts in Keystone since they already exist
>> and are managed by the trusted IDPs.
>>
>>
>>  The common userID is the account
>>> responsible for the actions of the ephemeral users.
>>
>> I simply dont see why you need this, or how it will help to authorise
>> users. In fact it will mess up the authz if the CSP uses the userID in
>> its access control lists, because in this case all users would have
>> the same access rights, which is not what is required.
>
> OK,  so the policy module knows about roles and has rules like
> "role:admin"  We can extend the attributes that the policy module can
> consume for rules, but it has to be a limited set.

Ultimately I would see the set comprising of known standard attributes 
that have meaning to Keystone (such as domains) and other attributes 
that are only known to the service and are used for authz, but are just 
blobs to keystone. By having a generic table for attributes, as you have 
suggested (which hold the current groups, domains, projects etc in the 
same table) then services can add their own attributes to this at will. 
By having a boolean column labelled "authz", this tells Keystone whether 
to include this attribute in the token or not. All the org attributes 
including groups would be labelled false, whilst projects, roles etc 
would be labelled true. Services can then add their own authz attributes 
as desired, including such things as "quota class" and "availability 
zone" as requested by Phil Day in his posting of on 30 Jan. The 
attribute mapping function would be set to map the IDP org attributes 
into the appropriate set of authz attributes, and Keystone would then 
pass these to the service in the token.

>
> Swift would have to enforce RBAC.

No not necessarily. We already have email address I believe as part of 
the token attributes. This is a unique ID for the user so ACLs can be 
built using this instead of the existing keystone user_ID. Since email 
address is part of a user's IDP set of attributes there would be a 
mapping from this to the existing Keystone email attribute.


  Data stored in swift would be "owned"
> by the project, not by the user.

I think this is a choice for the service to make. If the keystone token 
contains a set of authz attributes then the service can decide which set 
indicate ownership of which resources. In the system we built using 
Eucalyptus (see our demo at https://authz.tas3.kent.ac.uk/proxyS3/) the 
user is presented with a set of "accounts" that he owns by virtue of his 
set of authz attributes. So if Swift decided that ownership is based on 
email address then each user would have his own account. If it decided 
ownership was based on project then everyone in the project would own 
the account.

  Proejcts cannot be ephemeral in a
> federated system.

None of the authz attributes can be ephemeral in an ABAC system, since 
they are built into the policy engines and ACLs of the services. In fact 
these are the only things that really matter, since these are the only 
things that give users access to resources.

  If a user want to affect a change in swift, they need
> to have the appropriate roles for the stored object.  THose roles would
> be mapped from the attributes issued by the IDP.

this would be the case in a multi-user owned account, where each user 
has his own subset of resources in the account. But this might be a 
rather complex case. It might be simpler for each user to have his own 
set of accounts based on his identity attributes.

>
>
> Is it me, or are we in violent agreement on most points here?

Mostly in agreement I think, which is a relief :-)

>
>
>
>>
>>>
>>> The token will have a set of identity attributes in it, signed by
>>> Keystone.
>>
>> Actually it should have the mapped attributes in it, the ones that the
>> CSP knows and uses for authorising the users (especially if the CSP is
>> going to validate the token. There is no point in putting strange IDP
>> / organisational attributes in the token).
>>
>>  That is all the user needs, not a separate account in
>>> Keystone's user table.
>>
>> At last we agree on this. The user does not need a duplicate account
>> in Keystone.
>>
>>
>>>
>>> Another way of saying it is that we already have an ephemeral user
>>> construct, it is the token.
>>
>> Agreed.
> I wonder if we should use the token ID as the ephemeral user id?

No I think we should keep them separate, since they are different 
concepts. It is not usually a good idea to compact two concepts into one 
variable. For example in delegation (your trusts) the emphemeral user id 
may delegate to another ephemeral user id, and an emphemeral user might 
have multiple tokens at the same time. So I would suggest to keep them 
separate for the time being.

>
>>
>>>
>>>>
>>>> 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.
>>
>> But this is for the non-federated environment where users have to be
>> in the keystone database in order to authenticate and get tokens.
>>
>> In the federated world the users account is already in the IDP's
>> database (as is his pw).
>
> You need to set up the federation agreement.

this is true. And today this is done via contracts and other agreements 
between the various parties. Since one party is trusting another party 
to provide a service, there are many things to be agreed such as SLAs, 
cost, legal redress, privacy etc.

  I would see it happen by
> making an account in keystone which gets blessed as the IdP
> administrator.  We need to specify how the workflow will occur.

We have already done this in our blueprint

https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin

Have a read of this and see if it addresses your requirements. It allows 
the keystone admin to set up accounts for IDP admins and give them 
permissions to set up attribute mappings for the attributes they issue.

regards

David

>
>
>>
>> regards
>>
>> David
>>
>>>>
>>>> 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
>>>>>
>>>
>