Open Stack

Hi Adam

On 23/08/2012 18:39, Adam Young wrote:
> On 08/23/2012 12:38 PM, David Chadwick wrote:
>> Hi Adam
>>
>>
>>>> what do you mean by IDM provider? IDP?
>>>
>>> Yes.  Identity Management (IdM) system.
>>
>> IDM and IDP are not the same.
>> IDP is an identity provider who authenticates users and asserts
>> attributes about them (a combination of an Authentication Service and
>> an Attribute Authority)
>> IDM is a system which comprises many different entities such as
>> Discovery Service
>> IDP
>> AA
>> Service Providers
>> Aggregation Service
>> and more which may still need to be defined such as
>> proxy IDP
>> gateway
>> etc.
>
> OK, that is a clear distinction.  IdP has a smaller scope.  I'm used to
> working with them integrated,  but I see the value of the distinction.
> I'll try to stick with it for the discussion. Keystone blends the two
> into one, of course.

Great. The architecture doc I am producing shows each function as a 
separate service. Of course, a piece of software can implement multiple 
functions (as Keystone currently does), but separation of functionality 
allows clearer thinking and more modular construction. It also supports 
greater distribution and scalability.

>
>>
>>>
>>>>
>>>> can indicate
>>>>> that a given user is a member of a tenant,
>>>>
>>>> It is surely the cloud provider or keystone that controls the creation
>>>> of tenants isnt it?
>>>>
>>>>  and that the user has a given
>>>
>>>
>>> Yes, but Domain is a Keystone concept.  A Domain is a top level grouping
>>> of tenants.  Each user belongs in exactly one Domain, but can
>>> potentially get access to tenants in other domains.
>>
>> I have read your Domains document. A lot of it is to do with managing
>> users. But Keystone administrators should not be directly managing
>> users. IDPs should be doing this. What keystone administrators should
>> be doing is authorising users for their cloud resources, based on
>> their IdP provided attributes. I will try to write an architecture
>> document describing keystone with separate services with separate
>> functionality (rather than integrated ones). In our federated keystone
>> implementation the administrator does not manage users, rather he
>> authorises them to use services through a set of rules (essentially
>> attribute mappings ie. map their identity attributes from their IDPs
>> into OpenStack attributes (tenant id, role etc), and permissions
>> (through a PDP). In this way users are only managed (provisioned)
>> once, by their IdPs. Keystone does not need to bother about
>> authenticating users - the IDPs or Authentication services do this for
>> keystone.
>
> OK,  Let me see if I can restate it.
>
>
> The current implementation of Keystone is a degenerate case of a more
> complex solution space.  Currently, Keystone ties together the
> management of users and roles with the management of tenants.  It also
> lacks some higher level of distinction to group tenants,  which has been
> referred to as both Domains and Realms. In a Federated system, Keystone
> no longer directly manages Users, but instead delegates that to remote
> IdP systems.

agreed

The IdP is what determines the capabilites of a user, not
> the Keystone server.

to be more precise, the IDP determines the attributes of the user, and 
the service provider determines the permissions that are assigned to the 
attributes (its the classic RBAC model, only using attributes instead of 
roles).

Instead, the Keystone server plays an indirect
> role, merely determining whether a given IdP has the authority to
> delegate the requested action.

Actually this is the functionality of a separate component, which we 
call the credential validation service (which is part of what MS call 
the Security Token Service)

>
> I think that there are two use cases that are at odds here.  Lets call
> them Cloud to Organization (C2O) and Cloud  to User (C2U). Federated as
> you state is an elegant solution to C2O. Keystone as it currently exists
> is targeted at C2U.  We need both, which means that an organization
> implementing Openstack will still need its own IdP, but will also need
> to support other, federated, IdPs as well.

agreed. But all organisations already have their own IDPs, only they 
dont call them that. All organisations have databases (often LDAP) in 
which they provision users, assign them attributes, store their 
passwords etc. All they need in terms of extra technology is a protocol 
machine that can talk the federated protocol.

>
> I think there should be a conceptual one-to-one mapping between domains
> and IdPs, although in actuality one IdP could manage more than one domain.

True. In fact such IDPs have already been built - a type of outsourcing IDP.

>
>>>
>>>>> role in the tenant, but there needs to be some differentiation between
>>>>> the providers.  In the Federation doc
>>>>> http://wiki.openstack.org/Keystone  I suggest that a IdM is allowed to
>>>>> control one or more  domains.
>>>>
>>>> what do you mean by domain? I think of domain as a group of entities
>>>> under the same administrative control. So a Fed IDM (FIM) contains
>>>> lots of domains, but does not control them as each domain has its own
>>>> administrator. Usually each SP and each IDP is in its own domain.
>>>> Federation means that they are joining together for mutual benefit.
>>>> The FIM administrator will set rules for the FIM system as a whole,
>>>> and each domain administrator will agree to abide by them.
>>>
>>> http://wiki.openstack.org/Domains
>>
>> thanks for the pointer
>>
>>>
>>>>
>>>>  In order to get access to the tenants in
>>>>> that domain,
>>>>
>>>> I dont understand what you mean  by the tenants in that domain.
>>>>
>>>>  a user uses the auth mechanism for that domain, possible
>>>>> using a mechanism like cross realm support from Kerberos.
>>>>
>>>> the Kerberos cross realm support should not be part of the Keystone
>>>> design. This is a feature of how the user authenticates with the IDP.
>>>> Keystone is acting as a SP, and it has trust relationships with IDPs.
>>>> The cross realm (or cross domain) support comes from the SP trusting a
>>>> remote IDP ie. keystone being configured to trust one or more remote
>>>> IDPs.
>>>
>>> If I understand this correctly, I don't think this it is secure.
>>
>> you can design it with varying levels of security, ranging from bearer
>> tokens (the least secure) to holder of key tokens (where the user has
>> to prove possession of a private key).
>
> Ah, I was too terse.  Let me explain.
>
> Say two peer organizations have a setup where a user for one can modify
> resources owned by another.  Control of the permissions for the user has
> to be maintained under the control of the organization that owns the
> resources.

Absolutely. This is the beauty of RBAC, since it has user to attribute 
assignments (done by the IDP) and permission to attribute assignments 
(done by the SP)

  They cannot be modified by the other organization.  It is
> not a factor of the authentication mechanism, but of the authorization
> mechanism.

agreed.

>
>
>>
>>   A user has
>>> to get a role to effect a change to a resource inside the tenant.  That
>>> role has to be assigned by the administrator of the tenant. THat won't
>>> come out of the users Identity Management System, but out of the IdM for
>>> the Domain.
>>
>> It could come from attribute mappings (as stated above). The domain
>> manager can have a rule which states "a user with this attribute from
>> this IDP gets this role in this tenant"
> I am not thrilled with that.  Say I am using my Facebook (really big
> organization) account to validate against a tenant managed by the IdP
> for MomAndPopsLaundry.  I can't get Facebook to modify its set of
> attributes for me.  Instead, I need MomAndPopsLaundry to enable my
> account in their tenant.

I did not quite follow that, sorry. What we have done is used Facebook 
as the IDP to authenticate the user and provide a set of attributes to 
the SP, which then grants the user limited access. We have built this 
into a cloud demo here

https://authz.tas3.kent.ac.uk/proxyS3/

which we showed at Boston last year

and also into university services where we have a public demo here
https://persistence.kent.ac.uk/logins4life/

In fact all our demos are available from here
http://sec.cs.kent.ac.uk/demos/


>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>> and often one that is done in conjunction with an exchange of
>>>>>>> funds, or
>>>>>>> at least the intialization of a contract with the end user to be
>>>>>>> billed
>>>>>>> later.
>>>>>>
>>>>>> Agreed. We also assume that this has been done beforehand. E.g. The
>>>>>> CSP enters into a contract with my university to allow all staff to
>>>>>> store 3 GB of data in its cloud. The rule will say "if the user can
>>>>>> prove he is a member of staff from the University of Kent" then
>>>>>> create
>>>>>> a new tenant for him. How is this achieved. Easy. The user
>>>>>> authenticates via the Kent IDP, then the Kent IDP send a signed
>>>>> assertion to Keystone (via the client) saying "I have authenticated
>>>>>> this user. His PID is 1234556678, his role is staff member and his
>>>>>> organisation is University of Kent" signed by University of Kent IDP.
>>>>>> Only people with staff login credentials at the Kent IDP will be able
>>>>>> to obtain this signed assertion.
>>>>>>
>>>>>>
>>>>>>   On demand tenant creation would ariull need to tie in with such
>>>>>>> and accounting system.
>>>>>>
>>>>>> not sure what you were trying to say here
>>>>> Me neither.
>>>>>>
>>>>>>  I understand that different implementations have
>>>>>>> different requirements.   Would it be correct to say that this is
>>>>>>> something that should be a policy decision on the part of the
>>>>>>> implementation?
>>>>>>
>>>>>> Yes policy decision by the implementation. Policy specification by
>>>>>> the
>>>>>> CSP administrator.
>>>>>>
>>>>>>  Is there anything in your design which would require
>>>>>>> on-demand tenant creation?
>>>>>>
>>>>>> Yes, we dont know who the tenants are beforehand. And we dont want to
>>>>>> know. We must keep the cloud dynamic and responsive to the customers
>>>>>> (clients) needs. Consider the unnecessary overhead if Kent had to
>>>>>> configure 2000 users and their credentials into the CSP's system, as
>>>>>> well as into their own systems at kent. It duplicates the effort,
>>>>>> gives rise to errors, and is simply a costly waste of time.
>>>>> Tenant != User.  Tenant ~ group.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> You mention the client library.  I think that we want to go the
>>>>>>> other
>>>>>>> way:  straight REST implementation.  While it is true that the CLI
>>>>>>> has a
>>>>>>> lot of power, what we have found is that a huge number of
>>>>>>> implementations are using the Web APIs as the primary access to
>>>>>>> Openstack, and they need to be the first class citizen.
>>>>>>
>>>>>> Now this is interesting. Because at the summit in Boston last year I
>>>>>> gave a presentation entitled My Private Cloud where I demonstrated
>>>>>> that we had built a browser based federated interface to an Amazon S3
>>>>>> like service, and the main criticism given of it by the audience was
>>>>>> "most Open Stack users use a command line interface, not a browser
>>>>>> based one, so your system would not work well for our users". So this
>>>>>> time around we built onto the command line interfaces. Now you
>>>>>> seem to
>>>>>> be saying exactly the opposite!
>>>>>
>>>>> Ah, not quite.  I am saying that we have found a lot of our users are
>>>>> using the direct APIs as opposed to the CLIs that Openstack provides.
>>>>> Not browser based.  For those using the tools we provide, it is still
>>>>> CLI over Browser as well.
>>>>
>>>> this is where we will have potential problems, because all the IDPs I
>>>> know of today use browsers to authenticate their users. And the
>>>> authentication protocol between the IDP and the user is not
>>>> standardised by any of the identity management systems. So the IDP can
>>>> do anything it wants. There is no IDM API for this. And there probably
>>>> never will be as it defeats the purpose of having IDM and allowing
>>>> freedom in the choice of authentication mechanism.
>>>
>>> Kerberos does not.  PKI based system to do not.  SAML can be done
>>> without a Browser.  The browser, while a useful tool, cannot be a
>>> required part of the auth system.
>>
>> I agree that it does not have to be. But it makes things a lot simpler
>> if it is
>
> Yes, but it 100% cannot be a requirement.  Still, I don't think that is
> a big problem. It means that getting authenticated to a remote system
> has to be possible via a web service.  Shibboleth and SAML can both work
> that way.  What is done with redirects can be done explicitly.  Support
> for that can, potentially, go into the Openstack common client
> architecture.
>
> One thing that this does not address is fetching the service catalog on
> behalf of the end user.  THis is done in the auth_token middleware
> during verification. With PKI tokens, it is signed and embedded in the
> token.  The Federated middleware would need a way to query that for a
> user, without that user actually being in the Keystone database.

What you call the Catalog we call the Discovery Service. You will notice 
that we built the Disco service into our design.

There are different ways in implementing discovery. One way is to have 
some intelligence in the service, that given a user ID, knows where to 
direct the user to for authentication. (This is the way you use with 
PKCs). The other way is to get the user to choose himself (e.g. as in 
the WAYF service in Shibboleth, and the Nascar stickers on some web 
sites). The problem with both these methods is that the SP redirects the 
user to the IDP, and this is perfect for phishing attacks and stealing 
the user's credentials (if he uses a PW).

We have developed an alternative method of discovery that allows the 
user to direct himself to his own IDP without the SP telling him where 
to go to. Its part of our Trusted Attribute Aggregation Service (demo 5 
on our web site)


regards

David
>
>
>
>
>>
>> regards
>>
>> David
>>
>>>
>>>
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>> (rest cut)
>>>
>