The document describes a proposed federated identity management system for OpenStack clouds. It defines a federation as an association of service providers and identity providers. The current implementation uses a 3-tuple model of authorization that needs to be expanded to a 5-tuple model to incorporate federation and multi-tenancy. The proposed system uses a 5-tuple of (Issuer, Subject, Privilege, Interface, Object) along with an RBAC model. It then describes a simple mechanism for federation where a client obtains various tokens - GAT, TAT, and RAT - to access resources across different clouds. Finally, it compares this proposed model to an existing 30-step blueprint, noting differences in entities, tokens

1. Keystone Federation
Anush V
Meghana Prashanth
Pramod Ramesh
Dr. Dinkar Sitaram
Center for Cloud computing and Big Data
PESIT, Bangalore

2. Openstack A OpenstackB
IdentityProvider 1
IdentityProvider 1
Services k
Services l
Openstack C
IdentityProvider 1
Services m

3. Federation
• A federation is defined as “an association comprising any
number of
service providers and identity providers.

4. Federated System
• Current implementation of authorization is based on a 3-tuple implementation
namely (Subject, Privilege, Object)
• This needs to be modified to incorporate federation and multi-tenancy
• The new system would have a structure in the form of a 5-tuple namely (Issuer,
Subject, Privilege, Interface, Object)
• We use an RBAC incorporated implementation
• This new model which has RBAC changes the 5-tuple to (Issuer, role(Issuer,
roleName), Privilege, Interface, Object)

5. (IssuerB, role(IssuerA, admin), Read, InterfaceB.1, root) is interpreted
as IssuerB grants anybody with role(IssuerA, admin) Read access to
the root folder of the file system provided by InterfaceB.1.

6. Our Implementation
We have devised a simple mechanism for federation
Scenario: Assume that the client is a tenant in some Home cloud A. They want access to
resources in some remote cloud B.
• GAT acquisition: the client sends to the gateway in A a GAT (Gateway Access Token)
request that will allow it to access the gateway at B. The GAT is one of our 5-tuples.
• TAT acquisition (Tenant Access Token)
o The client sends the GAT, together with its certificate or authentication token, to the
gateway at R requesting a TAT .
o [The gateway at R contacts the gateway at H to validate the identity of the client.]
o The gateway at R returns a TAT for the requested or all accessible tenants. The TAT is
another of our 5-tuples.
• RAT acquisition (Resource acquisition Token):
o The client sends the TAT together with a request for a RAT to the policy engine on
the tenant.This should be signed.
o The policy engine sends the request to the gateway at R for verification of the
signature
o The policy engine sends back the RAT. The RAT is our 5-tuple.

7. Current implementation:
All rules are stored here
rules_dict : { abc: {role:[netadmin] , tenant_id:[mytenant] ,
def: {role:[computeadmin], tenant_id:[mytenant1]}
Service Access Requirements
match_list : {rule:abc} - Service determines what is the required policy to grant user access
User Credentials
cred_dict : { roles:[netadmin], tenant_id: [mytenant]}
target_dict : {tenant_id: mytenant} Our implementation:
All rules stored here
rules_dict: { abc: {role:[issuerA:netadmin], tenant_id:[mytenant],interface:[myinterface] ,
def: {role:[issuerC:netadmin], tenant_id:[mytenant], interface:[myinterface]}
Service Access Requirement
match_list : {rule:abc}
User Credentials
target_dict : {tenant_id:mytenant}
cred_dict : {roles:[issuerA:netadmin], tenant_id:[mytenant], interface:[myinterface]}

8. Current Federation Blueprint
• The current blueprint for federation is given by David Chadwick
• He talks about a 30 step procedure involving various entities like
• AM – Attribute Mapper
• ARP – Attribute Requirements Policy
• IdP – Identity Provider
• AA – Attribute Authority
• There exists a global entity called Openstack Gateway (OG) which is a centralised
control unit
• OG contains trust relationships between AA, IdPs, etc.
• Since all mappings are in OG there is a need to have globally identifiable
attributes/roles given by IdPs, AAs
• Existence of scoped and unscoped tokens (unclear)

9. Differences between the models
• ARP does not exist in our model. Instead we feel directly sending the users
credentials is enough
• There is no explicit IdP in our model. Instead the authenticity of the user is
validated by its gateway by looking at the user generated certificate
• AM is not needed in our model
• Our model has local gateways for each of the cloud service providers as
compared to a common Openstack Gateway proposed by the blueprint
• There are just normal tokens in our model. The blueprint talks about scoped and
unscoped tokens

10. THANK YOU