Keystone Federation

10

Click here to load reader

Transcript of Keystone Federation

Page 1: Keystone Federation

Keystone Federation

Anush V

Meghana Prashanth

Pramod Ramesh

Dr. Dinkar Sitaram

Center for Cloud computing and Big Data

PESIT, Bangalore

Page 2: Keystone Federation

Openstack A OpenstackB IdentityProvider 1 IdentityProvider 1 Services k Services l

Openstack C IdentityProvider 1 Services m

Page 3: Keystone Federation

Federation

• A federation is defined as “an association comprising any number of

service providers and identity providers.

Page 4: Keystone Federation

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)

Page 5: Keystone Federation

(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.

Page 6: Keystone Federation

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.

Page 7: Keystone Federation

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]}

Page 8: Keystone Federation

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)

Page 9: Keystone Federation

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

Page 10: Keystone Federation

THANK YOU