Keystone Federation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Keystone Federation

on

  • 1,539 views

 

Statistics

Views

Total Views
1,539
Views on SlideShare
1,539
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Keystone Federation Presentation Transcript

  • 1. Keystone Federation Anush V Meghana Prashanth Pramod Ramesh Dr. Dinkar Sitaram Center for Cloud computing and Big Data PESIT, Bangalore
  • 2. Openstack A OpenstackBIdentityProvider 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 interpretedas IssuerB grants anybody with role(IssuerA, admin) Read access tothe root folder of the file system provided by InterfaceB.1.
  • 6. Our ImplementationWe have devised a simple mechanism for federationScenario: Assume that the client is a tenant in some Home cloud A. They want access toresources 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 hererules_dict : { abc: {role:[netadmin] , tenant_id:[mytenant] , def: {role:[computeadmin], tenant_id:[mytenant1]}Service Access Requirementsmatch_list : {rule:abc} - Service determines what is the required policy to grant user accessUser Credentialscred_dict : { roles:[netadmin], tenant_id: [mytenant]}target_dict : {tenant_id: mytenant} Our implementation:All rules stored hererules_dict: { abc: {role:[issuerA:netadmin], tenant_id:[mytenant],interface:[myinterface] , def: {role:[issuerC:netadmin], tenant_id:[mytenant], interface:[myinterface]}Service Access Requirementmatch_list : {rule:abc}User Credentialstarget_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