[openstack-dev] [Keystone] Federated design from Kent

David Chadwick d.w.chadwick at kent.ac.uk
Fri Aug 24 08:39:14 UTC 2012


On 24/08/2012 02:14, Matt Joyce wrote:
> Reiterating old point.  I'd love if I could get kerberos tickets passed
> via keystone API.

Hi Matt

I believe in our design your can. This is because the Disco service 
creates application specific blobs which Keystone passes as opaque blobs 
to the client, for it to forward to the IDP (kerberos in your case), and 
the response from the IDP is again passed as an opaque blob via the 
client to Keystone to the Credential Validation Service, which then 
tells Keystone the user is authenticated. The return blob would be the 
token from the TGS, and Keystone would be the kerberos service. The CVS 
would share a secret key with the TGS, enabling it to decode the message.

regards

David

>
> -Matt
>
> On Thu, Aug 23, 2012 at 5:49 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 08/23/2012 03:41 PM, David Chadwick wrote:
>
>
>
>         On 23/08/2012 19:59, Adam Young wrote:
>
>         CUT
>
>
>             If two users have identical attributes, with the exception
>             of their
>             username and userId number, and only one of them should get
>             access to
>             MomAndPopsLaundry,  then the Admin at MomAndPopsLaundry  has
>             to grant
>             the permissions to that userid.
>
>
>         correct. Username and userID are simply attributes such as role
>         and favouriteDrink. The only difference is that each uniquely
>         identifies the user in the domain whereas the others do not. So
>         they are identifiers. The Admin can select another
>         differentiating attribute such as email address (which is also
>         an identifier). It is unlikely that two users will have all
>         their attributes identical.
>
>             This works, but it doesn't scale.
>
>
>         If MomAndPop want to give different permissions to each
>         individual user, then it is their model that does not scale. Its
>         not the FIM model.
>         If MomAndPop want to select individual users from different IDPs
>         then of course they will need to use attributes that are
>         identifiers, otherwise they will select a group of users with
>         each attribute. I am pretty sure that all IDP protocols can send
>         a unique PID for each user with the attribute assertions, so
>         there is always a way to uniquely identify each individual user.
>
>
>             Instead, the user should be put into a grouping from the
>             MomAndPopsLaundry's IdP that then provides the roles.
>
>
>         But this may not uniquely identify a single user
>
>
>     Right.  What I would assume is that they would have some grouping,
>     say "contract_administrators"  and each user would get listed in
>     there....but perhaps that is really no different than
>     what you are sugggesting:  the policy engine would just have a list
>     of userids instead of storing them inside the IdM database.  But
>     seems like it should go in IdM, and be served by IdP, instead of
>     being maintained as part of the policy.  Typically, you don't want
>     to deploy new policy rules just because a user was added to or
>     removed from a group.
>
>
>     In a Kerberized system, this would be done via a service ticket
>     issued using a cross domain trust.  I think that is the right model:
>       you have to go to the other IdP in order to get a credential for
>     their resources.  Then the other IdM maintains a list of remote
>     users, from multiple domains.
>
>
>
>
>
>
>
>         regards
>
>         David
>
>
>             I'll take a look at the demos above and see if they meet my
>             concerns.
>
>
>
>
>     _________________________________________________
>     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 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>



More information about the OpenStack-dev mailing list