Keystone Federation

  • 897 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
897
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

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