KEYSTONE / Module 1 / Slideshow 1 / KEYSTONE Course: Getting Oriented
Keystone Federation
Click here to load reader
-
Upload
openstackindia -
Category
Technology
-
view
1.063 -
download
5
Transcript of Keystone Federation
![Page 1: Keystone Federation](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/1.jpg)
Keystone Federation
Anush V
Meghana Prashanth
Pramod Ramesh
Dr. Dinkar Sitaram
Center for Cloud computing and Big Data
PESIT, Bangalore
![Page 2: Keystone Federation](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/2.jpg)
Openstack A OpenstackB IdentityProvider 1 IdentityProvider 1 Services k Services l
Openstack C IdentityProvider 1 Services m
![Page 3: Keystone Federation](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/3.jpg)
Federation
• A federation is defined as “an association comprising any number of
service providers and identity providers.
![Page 4: Keystone Federation](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/4.jpg)
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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/5.jpg)
(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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/6.jpg)
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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/7.jpg)
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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/8.jpg)
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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/9.jpg)
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](https://reader038.fdocuments.net/reader038/viewer/2022100517/554c0bc6b4c905390b8b5765/html5/thumbnails/10.jpg)
THANK YOU