Re: [Openstack] [Keystone] Splitting the Identity Backend
Hi Adam I would propose splitting the backend into two conceptually distinct types of attributes, and then each of these high level types can be arbitrary split into different databases depending upon their sources of authority and who administers them. Your proposal would be just one specialisation of this more general model. The high level distinction I would make is between (read only) identity attributes and (writable) authorisation attributes. The latter are the ones used by the OpenStack services for making access control decisions, whilst the former are never used or seen by the OpenStack services, but are used by organisations to identify and group users into different sets. So HR databases and LDAP servers typically store these identity attributes. An attribute mapping function is needed to map between the former and the latter. We can then organise the user login function as follows: 1. A user logs in and is identified and authenticated, and a set of identity attributes are assigned to him by the authentication function. This could be from a read only LDAP service, or by a federated IDP. It should be pluggable and installation dependent. It could even be done by the user presenting an X.509 certificate and the information extracted from it. This part of Keystone should be highly flexible and adaptable to suit different deployment models. 2. The attribute mapping function maps from his identity attributes to his authz attributes. This can be a null mapping function if needed e.g. if the read only backend LDAP happens to store the users OpenStack projects and roles. But in most cases it will not be null. The mappings are set up by the Keystone administrator. 3. The users authz attributes are stored in his Keystone entry, which must be a writeable database owned by Keystone. Each time the user logins, his authz attributes will be updated to match his current identity attributes. So if an organisation promotes an employee, and changes his LDAP attributes, this could have the effect of automatically escalating his rights in Openstack. Conversely, if an employee is demoted, his rights in OpenStack could be automatically downgraded. It would all depend upon what the mapping rules were ie. whether they were fixed to a user's login ID (in which case his authz attributes would not change) or whether they depended upon his roles in his organisation (in which case they would automatically change). 4. The token is created based on his authz attributes as now, and everything continues as now. So taking the current mix of identity attributes that you identify below, they would be split as follows Domains, Roles, and Projects would be stored in Keystone's writeable database (as they are authz attributes) Groups and User Names (and Passwords) would be stored in the read only identity databases. Role assignments would be done by the attribute mapping function. If you want to split Domains into their own separate Keystone database, this fine, it does not effect the overall model. So, your proposal fits into this high level model, but this high level model provides much more flexibility to implementers and will allow for future expansion regards David On 20/05/2013 17:46, Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP backend. Identity would contain users and groups. Projects would contain Projects, Roles, and Role Assignments. Domains would contain only domains. For people happily deploying SQL, nothing should change. A single Database instance can still serve all three backends. It should only mean removing some foreign key constraints. For people that are deploying the current LDAP code and are happy with the layout, we will continue to support the LDAP Project backend. Say an organization has two LDAP servers, and also maintains a public facing cloud backed by SQL. Each of the two LDAP servers would have configurations that correspond to the current layout, although limited only to the user and group subtrees. The domain registry would live in the SQL backend. It would have two entries for the LDAP servers, and these would be immutable. Dynamic domain allocation and deletion would work only for the
Re: [Openstack] keystone middleware
Hi Pat do you expect the one central user store to be replicated, say in Keystone, or not replicated? The approach we have taken is to assume that the user stores (we support multiple distributed ones) are external to Keystone, and will be managed by external administrators. When a user accesses OpenStack, a transient entry is created in Keystone's user database for the duration of the SSO token, and is then automatically removed afterwards. This does not effect role based access controls, but will effect ACLs that currently use user IDs to identify the user, since these will change for different login sessions. The solution is for the ACL to use a persistent identity attribute of the user which comes from the user store, rather than to use the transient Keystone user ID regards David On 18/02/2013 16:16, pat wrote: Hi David, Well, it might be useful. I forget to add that I expect one (central) user store. Thanks Pat On Mon, 18 Feb 2013 16:11:05 +, David Chadwick wrote Hi Pat sounds like you need our federation software which was designed specifically for this use case. We currently support SAML as the SSO protocol, and have just added Keystone to Keystone SSO. I have also written a blueprint to show how OAuthv2 and OpenConnect can be used by writing custom plugin modules. So if you have your own proprietary SSO protocol you can write plugin modules for this Kristy can let you Pat have an alpha version for testing if he wants it. regards David On 18/02/2013 15:59, pat wrote: Hello, Sorry to disturb, but I have some questions regarding keystone middleware. Some introduction to problem: I need to integrate OpenStack to our existing infrastructure where all systems are integrated on REST and Web level using SSO-like system (there's generated a token string with specific information). Required behavior is to allow users log-in once in existing infrastructure and without additional log-in access OpenStack components. I assume this is possible by implementing custom keystone drivers for identity and token. Is that correct? Should I also implement new policy and/or catalog driver? If this is possible I expect the keystone token is the token generated by my middleware driver(s) and such token is used by all other OpenStack parts. Is that correct? Does this affect way how the OpenStack internally validates token? Now when validating token the admin token has to be passed to validation request too. I expect not. Is there possible to chain more keystone authentication drivers? E.g. first check my custom and if this one fails then check SQL one. I've searched internet to find some example of keystone middleware, but I didn't succeed :-\ Is there an example or step by step documentation (something for an ... :-))? I've read Middleware Architecture documentation and my questions are based on this. Thanks a lot for your help. Pat Freehosting PIPNI - http://www.pipni.cz/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Freehosting PIPNI - http://www.pipni.cz/ Freehosting PIPNI - http://www.pipni.cz/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone middleware
Hi Pat sounds like you need our federation software which was designed specifically for this use case. We currently support SAML as the SSO protocol, and have just added Keystone to Keystone SSO. I have also written a blueprint to show how OAuthv2 and OpenConnect can be used by writing custom plugin modules. So if you have your own proprietary SSO protocol you can write plugin modules for this Kristy can let you Pat have an alpha version for testing if he wants it. regards David On 18/02/2013 15:59, pat wrote: Hello, Sorry to disturb, but I have some questions regarding keystone middleware. Some introduction to problem: I need to integrate OpenStack to our existing infrastructure where all systems are integrated on REST and Web level using SSO-like system (there's generated a token string with specific information). Required behavior is to allow users log-in once in existing infrastructure and without additional log-in access OpenStack components. I assume this is possible by implementing custom keystone drivers for identity and token. Is that correct? Should I also implement new policy and/or catalog driver? If this is possible I expect the keystone token is the token generated by my middleware driver(s) and such token is used by all other OpenStack parts. Is that correct? Does this affect way how the OpenStack internally validates token? Now when validating token the admin token has to be passed to validation request too. I expect not. Is there possible to chain more keystone authentication drivers? E.g. first check my custom and if this one fails then check SQL one. I've searched internet to find some example of keystone middleware, but I didn't succeed :-\ Is there an example or step by step documentation (something for an ... :-))? I've read Middleware Architecture documentation and my questions are based on this. Thanks a lot for your help. Pat Freehosting PIPNI - http://www.pipni.cz/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone delegate Athentication
This is already available in a side branch of the Git hub in the federation code, written to support the following blueprint: https://blueprints.launchpad.net/keystone/+spec/federation We have a number of people already experimenting with the above code. We have a newer version available in our labs which also supports the following blueprints: https://blueprints.launchpad.net/keystone/+spec/role-mapping-service-keystone https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog https://blueprints.launchpad.net/keystone/+spec/mapping-distributed-admin Let me know if you would like an alpha copy of the above for testing regards David On 06/02/2013 14:54, Mballo Cherif wrote: Hi everybody ! I am wondering if it’s possible to delegate keystone Authentication to an Authentication against a server (I have one Strong Authentication server) or an Identity Provider? If I make modification on keystoneclient code it may be possible? Any ideas? Please help me! Thanks ! Sherif! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Hi Adam you have pointed out an important difference between an unscoped token and a scoped one. The former can only be used with keystone, the latter with a cloud service. This also implies that a scoped token can only have the scope of a single service, and not multiple services. The user must swap the unscoped token for a set of scoped tokens if he wishes to access a set of cloud services. This model is clean and consistent. Concerning your attack scenario, then the best point of attack is either the client (steal his token(s)) or Keystone (get access to any service) regards David On 13/11/2012 14:38, Adam Young wrote: On 11/10/2012 10:58 AM, David Chadwick wrote: I agree with the vast majority of what Jorge says below. The idea I would like to bounce around is that of the unscoped token. What does it mean conceptually? What is its purpose? Why do we need it? Why should a user be given an unscoped token to exchange at a later time for a scoped token? My view is as follows: i) a user is authenticated and identified, and from this, keystone can see that the user has access to a number of different tenants and services. Keystone creates an unscoped token to encapsulate this. Note that the unscoped token is scoped to the services/tenants available to this user, and consequently it is different for each identified user. Thus it does have some scope i.e. it cannot be swapped for access to any service by any tenant. ii) the user must choose which service/tenant he wishes to activate. This is in line with the principle of least privileges. iii) the user informs keystone which service(s) and tenant(s) he wishes to access and Keystone swaps the unscoped token for one that is scoped to the choice of the user. The issue then becomes, what is the allowable scope of a scoped token? Jorge below believes it should cover multiple services/endpoints/tenants. So one must then ask, what is the difference between the most widely scoped scoped-token and the unscoped token? Surely they will have the same scope won't they? In which case there is no need for both concepts. let's compare with Kerberos: In my view an unscoped token is comparaable with a ticket granting ticket: it cannot be used with any service other than the KDC, and it can only be used to get service tickets. A service ticket can only be used with a specific service. If that service gets compromised, any tickets it has are useless for access to other resources. If an unscoped token can be used against a wide array of services, we have just provided a path for an elevation of privileges attack. If I know that a service consumes tokens which can be used on a wide number of other services, I can target my attacks against that service in order to get access everywhere. If we are going to provide this functionality, it should be turned off by default. Comments please regards David On 23/10/2012 06:25, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine too. On scoping a token to a specific endpoint: That's fine, though I believe that that's in the API today. Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I'm not sure if the default middleware checks for this yet, but the Repose middleware does. If you try to use a token in an endpoint that's not in the service catalog the request fails -- well, if the check is turned on. Obviously, I'd like the idea of scoping a single token to multiple tenants / endpoints. I don't like the idea of calling tokens sloppy tokens -- it's confusing. All you have to say is that a token has a scope -- and the scope of the token is the set of resources that the token can provide access to. You can limit the scope of a token to a tenant, to a endpoint, to a set of endpoints or tenants etc -- what limits you place on the scope of an individual token should be up to the operator. Keep in mind that as we start digging into delegation and fine grained authorization (after Grizzly, I'm sure), we'll end up with tokens that have a scope of a subset of resources in a single or multiple tenants. So calling them sloppy now is just confusing. Simply stating that a token has a scope (as I've defined above) should suffice. This is part of the reason why I've never liked the term unscoped token, because an unscoped token does have a scope. It just so happens that the scope of that token is the resource that provides a list of available tenants. -jOrGe W. On Oct 22, 2012, at 9:57 PM, Adam Young wrote: Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Hi Guang On 13/11/2012 16:14, Yee, Guang wrote: An unscoped token is basically implicitly scoped to Keystone service right? One should be able to use an unscoped token to reset his password, and ask Keystone for information pertaining to himself, such as what are his roles, what services/endpoints are available to him, and what are his tenants, etc. This is helpful for administration UIs such as MC. agreed There's a blueprint to address the need to scope the token down to the service or endpoint level. Basically, service and endpoint isolation. I have read your blueprint and I have some comments/questions on it. How do you want these to be addressed? By email, or by edits to you blueprint? regards David https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles- delegation http://wiki.openstack.org/Keystone/Service-Isolation-And-Roles-Delegation It also addresses the intricacies of role delegation, which should be very beneficial for cloud services. Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of David Chadwick Sent: Tuesday, November 13, 2012 7:32 AM To: Adam Young Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Hi Adam you have pointed out an important difference between an unscoped token and a scoped one. The former can only be used with keystone, the latter with a cloud service. This also implies that a scoped token can only have the scope of a single service, and not multiple services. The user must swap the unscoped token for a set of scoped tokens if he wishes to access a set of cloud services. This model is clean and consistent. Concerning your attack scenario, then the best point of attack is either the client (steal his token(s)) or Keystone (get access to any service) regards David On 13/11/2012 14:38, Adam Young wrote: On 11/10/2012 10:58 AM, David Chadwick wrote: I agree with the vast majority of what Jorge says below. The idea I would like to bounce around is that of the unscoped token. What does it mean conceptually? What is its purpose? Why do we need it? Why should a user be given an unscoped token to exchange at a later time for a scoped token? My view is as follows: i) a user is authenticated and identified, and from this, keystone can see that the user has access to a number of different tenants and services. Keystone creates an unscoped token to encapsulate this. Note that the unscoped token is scoped to the services/tenants available to this user, and consequently it is different for each identified user. Thus it does have some scope i.e. it cannot be swapped for access to any service by any tenant. ii) the user must choose which service/tenant he wishes to activate. This is in line with the principle of least privileges. iii) the user informs keystone which service(s) and tenant(s) he wishes to access and Keystone swaps the unscoped token for one that is scoped to the choice of the user. The issue then becomes, what is the allowable scope of a scoped token? Jorge below believes it should cover multiple services/endpoints/tenants. So one must then ask, what is the difference between the most widely scoped scoped-token and the unscoped token? Surely they will have the same scope won't they? In which case there is no need for both concepts. let's compare with Kerberos: In my view an unscoped token is comparaable with a ticket granting ticket: it cannot be used with any service other than the KDC, and it can only be used to get service tickets. A service ticket can only be used with a specific service. If that service gets compromised, any tickets it has are useless for access to other resources. If an unscoped token can be used against a wide array of services, we have just provided a path for an elevation of privileges attack. If I know that a service consumes tokens which can be used on a wide number of other services, I can target my attacks against that service in order to get access everywhere. If we are going to provide this functionality, it should be turned off by default. Comments please regards David On 23/10/2012 06:25, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine too. On scoping a token to a specific endpoint: That's fine, though I believe that that's in the API today. Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I'm not sure if the default middleware checks for this yet, but the Repose middleware does. If you try to use a token in an endpoint that's not in the service catalog the request fails -- well, if the check is turned on. Obviously, I'd like the idea
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
seems like we need a clear design for next generation tokens that everyone can agree on. But also an extensible design to cater for outliers. In our federation design doc we show the Token Issuing Service and Token Validation Service as plugin modules to Keystone that can be replaces so that outliers can replace the standard service with one of their own choosing regards David On 13/11/2012 17:35, heckj wrote: So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. Right now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they'd need a different middleware there. Keystone as a service *doesn't* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user. All that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. - joe On Nov 13, 2012, at 9:17 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Hi Guang On 13/11/2012 16:14, Yee, Guang wrote: An unscoped token is basically implicitly scoped to Keystone service right? One should be able to use an unscoped token to reset his password, and ask Keystone for information pertaining to himself, such as what are his roles, what services/endpoints are available to him, and what are his tenants, etc. This is helpful for administration UIs such as MC. agreed There's a blueprint to address the need to scope the token down to the service or endpoint level. Basically, service and endpoint isolation. I have read your blueprint and I have some comments/questions on it. How do you want these to be addressed? By email, or by edits to you blueprint? regards David https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles- delegation http://wiki.openstack.org/Keystone/Service-Isolation-And-Roles-Delegation It also addresses the intricacies of role delegation, which should be very beneficial for cloud services. Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of David Chadwick Sent: Tuesday, November 13, 2012 7:32 AM To: Adam Young Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Hi Adam you have pointed out an important difference between an unscoped token and a scoped one. The former can only be used with keystone, the latter with a cloud service. This also implies that a scoped token can only have the scope of a single service, and not multiple services. The user must swap the unscoped token for a set of scoped tokens if he wishes to access a set of cloud services. This model is clean and consistent. Concerning your attack scenario, then the best point of attack is either the client (steal his token(s)) or Keystone (get access to any service) regards David On 13/11/2012 14:38, Adam Young wrote: On 11/10/2012 10:58 AM, David Chadwick wrote: I agree with the vast majority of what Jorge says below. The idea I would like to bounce around is that of the unscoped token. What does it mean conceptually? What is its purpose? Why do we need it? Why should a user be given an unscoped token to exchange at a later time for a scoped token? My view is as follows: i) a user is authenticated and identified, and from this, keystone can see that the user has access to a number of different tenants and services. Keystone creates an unscoped token to encapsulate this. Note that the unscoped token is scoped to the services/tenants available to this user, and consequently it is different for each identified user. Thus it does have some scope i.e. it cannot be swapped for access to any service by any tenant. ii) the user must choose which service/tenant he wishes to activate. This is in line with the principle of least privileges. iii) the user informs keystone which service(s) and tenant(s) he wishes to access and Keystone swaps the unscoped token for one that is scoped to the choice of the user. The issue then becomes, what is the allowable scope of a scoped token? Jorge below believes it should cover multiple services/endpoints/tenants. So one must then ask, what is the difference between the most widely scoped scoped-token and the unscoped token? Surely they will have the same scope won't they? In which case there is no need for both concepts. let's compare with Kerberos: In my view an unscoped token is comparaable with a ticket granting ticket: it cannot be used with any service other
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
I agree with the vast majority of what Jorge says below. The idea I would like to bounce around is that of the unscoped token. What does it mean conceptually? What is its purpose? Why do we need it? Why should a user be given an unscoped token to exchange at a later time for a scoped token? My view is as follows: i) a user is authenticated and identified, and from this, keystone can see that the user has access to a number of different tenants and services. Keystone creates an unscoped token to encapsulate this. Note that the unscoped token is scoped to the services/tenants available to this user, and consequently it is different for each identified user. Thus it does have some scope i.e. it cannot be swapped for access to any service by any tenant. ii) the user must choose which service/tenant he wishes to activate. This is in line with the principle of least privileges. iii) the user informs keystone which service(s) and tenant(s) he wishes to access and Keystone swaps the unscoped token for one that is scoped to the choice of the user. The issue then becomes, what is the allowable scope of a scoped token? Jorge below believes it should cover multiple services/endpoints/tenants. So one must then ask, what is the difference between the most widely scoped scoped-token and the unscoped token? Surely they will have the same scope won't they? In which case there is no need for both concepts. Comments please regards David On 23/10/2012 06:25, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine too. On scoping a token to a specific endpoint: That's fine, though I believe that that's in the API today. Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I'm not sure if the default middleware checks for this yet, but the Repose middleware does. If you try to use a token in an endpoint that's not in the service catalog the request fails -- well, if the check is turned on. Obviously, I'd like the idea of scoping a single token to multiple tenants / endpoints. I don't like the idea of calling tokens sloppy tokens -- it's confusing. All you have to say is that a token has a scope -- and the scope of the token is the set of resources that the token can provide access to. You can limit the scope of a token to a tenant, to a endpoint, to a set of endpoints or tenants etc -- what limits you place on the scope of an individual token should be up to the operator. Keep in mind that as we start digging into delegation and fine grained authorization (after Grizzly, I'm sure), we'll end up with tokens that have a scope of a subset of resources in a single or multiple tenants. So calling them sloppy now is just confusing. Simply stating that a token has a scope (as I've defined above) should suffice. This is part of the reason why I've never liked the term unscoped token, because an unscoped token does have a scope. It just so happens that the scope of that token is the resource that provides a list of available tenants. -jOrGe W. On Oct 22, 2012, at 9:57 PM, Adam Young wrote: Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine by me. -jOrGe W. On Oct 21, 2012, at 11:10 AM, Joe Savak wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Scope should always be kept as limited as possible. Personally, I don't feel like limiting the tenant list makes much difference. THe more I think about it, the real benefit comes from limiting the endpoints. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: *From: *heckj he...@mac.com mailto:he...@mac.com *Subject: **[openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API* *Date: *October 19, 2012 1:51:16 PM PDT *To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org *Reply-To: *OpenStack Development Mailing List openstack-...@lists.openstack.org
Re: [Openstack] [keystone] Domain Name Spaces
On 27/10/2012 00:17, Henry Nash wrote: So to pick up on a couple of the areas of contention: a) Roles. I agree that role names must stay globally unique. One way of thinking about this is that it is not actually keystone that is creating the role name space it is the other services (Nova etc.) by specifying roles in their policy files. Until those services support domain specific segmentation, then role names stay global. I addressed this issue in my Federation design doc (in Appendix 2). Here is the text to save you having to look it up (note that an attribute is simply a generalisation of role and is needed in the broader authz context. Roles are too limiting.) Attributes may be globally defined, e.g. visa attributes, or locally defined e.g. member of club X. Globally defined attributes are often specified in international standards and may be used in several different domains and federations. Their syntax and semantics are fixed, regardless of which Attribute Authority (AA) issues them. Local attributes are defined by their issuing attribute authority and usually are only valid in the domain or federation in which the AA is a member. For locally identifiable attributes the attribute authority (issuer) must be globally identifiable (in the federation). The attribute then becomes globally identifiable through hierarchical naming (AA.attribute). Whilst in a non-federated world the service provider (e.g. Swift) can unilaterally define the roles it wants, in a federated world the attributes have to be mutually agreed between the issuer (AA) and the consumer (e.g. Swift). To address this issue I proposed a role mapping (attribute mapping) service that is run by Keystone, and it maps between the role/attribute required by the service, and the actual attribute issued by the AA. For example, say Swift requires the role of Admin to be assigned to addministrators, whereas company X, the attribute authority, assigns the LDAP attribute title=OpenStack Cloud Administrator to its admin staff. Keystone will use its attribute mapping service to map between these values. b) Will multi-domains make it more complicated in terms of authorisation - e.g. will the users have to input a Domain Name into Horizon the whole time? The first thing I would say is that if the cloud administrator has create multiple domains, then the keystone API should indeed require the domain specification. Again, in our federated design document we have the concept of a realm, which is similar to that of a domain, only in the federated case it indicates the place where the user will be authenticated and obtain (some of) his authz attributes from. The user can indicate the realm/domain name on the command line, but if it is missing, Keystone replies with a list of domains that it knows about and asks the user to choose one from the list. However, that should not mean it should be laborious for a Horizon user. In the case where a Cloud Provider has created domains to encapsulate each of their customers - then if they want to let those customer use horizon as the UI, then I would think they want to be able to give each customer a unique URL which will point to a Horizon that knows which domain to go to. this is certainly a possibility. regards David Maybe the url contains the Domain Name or ID in the path, and Horizon pulls this out of its own url (assuming that's possible) and hence the user is never given an option to chose a domain. A Cloud Admin would use a non domain qualified url to get to Horizon (basically as it is now) and hence be able to see the different domains. Likewise, in the case of where the Cloud Provider has not chosen to create any individual domains (and is just running the cloud in the default domain), then the non domain qualified url would be used to a Horizon that only showed one, default domain and hence no choice is required. Henry On 26 Oct 2012, at 17:31, heckj wrote: Bringing conversation for domains in Keystone to the broader mailing lists. On Oct 26, 2012, at 5:18 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: I think this discussion would be great for both mailing lists. -Dolph On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash henry.n...@mac.com mailto:henry.n...@mac.com wrote: Hi Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec. Here's my view as an opening gambit: - When a Keystone instance is first started, there is only one, default, Domain. The Cloud Provider does not need to create any new domains,
Re: [Openstack] [keystone] Re: Domain Name Spaces
On 26/10/2012 17:31, heckj wrote: Bringing conversation for domains in Keystone to the broader mailing lists. On Oct 26, 2012, at 5:18 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: I think this discussion would be great for both mailing lists. -Dolph On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash henry.n...@mac.com mailto:henry.n...@mac.com wrote: Hi Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec. Here's my view as an opening gambit: - When a Keystone instance is first started, there is only one, default, Domain. The Cloud Provider does not need to create any new domains, all projects can exist in this default domain, as will the users etc. There is one, global, name space. Clients using the v2 API will work just fine. +1 Very much what we were thinking for the initial implemenation and rollout to make it backwards compatible with the V2 (non-domain) core API - If the Cloud Provider wants to provide their customers with regions they can administer themselves and be self-contained, then they create a Domain for each customer. It should be possible for users/roles to be scoped to a Domain so that (effectively) administrative duties can be delegated to some users in that Domain. So far so good - all this can be done with the v3 API. Not clear on if you're referring to endpoint regions, or just describing domain isolation? I believe you're describing the key use cases behind the domains mechanism to begin with - user and project partitioning to allow for administration of those to be clearly owned and managed appropriately. - We still have work to do to make sure items in other OS projects that reference tenants (e.g. Images) can take a Domain or Project ID, but we'll get to that soon enough Everything will continue to work with projects, but once middleware starts providing a DOMAIN_ID and DOMAIN_NAME to the underlying service, it'll be up to them to take advantage of it. Images per domain is an excellent example use case. - However, Cloud Providers want to start enabling enterprise customers to run more and more of the workloads in OpenStack clouds - over and above, the smaller sized companies that are doing this today. For this to work, the encapsulation of a Domain need, I think, to be able to be stricter - and this is where the name space comes into play. I think we need to allow for a Domain to have its own namespace (i.e. users, roles, projects etc.) as an option. I see this as a first step to allowing each Domain to have its own AuthZ/N service (.e.g external ldap owned and hosted by the customer who will be using the Domain) Implementation: - A simplistic version would just allow a flag to specified on Domain creation that said whether this a private or shared Domain. Shared would use the current global name space (and probably be the default for compatibility reasons). I like the direction of this -- need to digest implications :) I like the idea conceptually - but let's be clear on the implications to the end users: Where we're starting is preserving a global name space for project names and user names. Allowing a mix of segregated and global name spaces imposes a burden of additional data being needed to uniquely place authentication and authorization. We've been keeping to 2 key pieces of info (username, password) to get authenticated - and then (via CLI or Horizon dashboard) you can choose from a list of protential projects and carry on. In most practical circumstances, any user working primarily from the CLI is already providing 3-4 pieces of information: * username * password * tenant name * auth_url In fact these are all name/value pairs, so they can all be regarded as attribute names and values (or types and values in LDAP terminology). The attribute names/types have to be globally unique. I think you have implicitly mandated this in Keystone by defining the names yourself, and by not allowing other names to be used. I presume that currently it would not be meaningful to pass a value of * age via the CLI. But it should be, since one might have an authz policy that bases its decision on the age of the user. So how about considering a more generic interface where any attribute name and value can be passed, and the authz service will use these to see if they fit the policy or not. regards David to access and use the cloud. By allowing domains to be their own namespaces, we're adding
Re: [Openstack] [keystone] Domain Name Spaces
Hi Gabriel there is something of an oxymoron in one of your statements below By design, authentication will fail if they don't specify a domain (since you won't exist in the global domain) If the global domain is truly global then it should encompass all public and private (sub)domains. Otherwise it is not global. It is quite easy to include private name spaces in a global name space by using hierarchical naming. Firstly ensure that domain names match the naming of the global name space. Secondly append the name of the private domain to that of the local name to turn the latter into a global name. If you are familiar with Eduroam, the pan_European wireless authentication infrastructure, this is precisely what it does. When I log in at Kent, I use my kent user id and password. When I log in to Eduroam from somewhere else in Europe (or even at kent) I use my kent user id and prepend @kent.ac.uk, and the infrastructure automatically routes my request and pw to the kent authentication server for validation (via Radius). We should be considering this sort of federated feature (or something like it) for Keystone with domains regards David On 30/10/2012 08:00, Henry Nash wrote: Gabriel, So I think you are right to ask that this is made clear and concrete - I'll work with the core contributors of Keystone to make it so. To your specific point: - Let's call the initial Domain, the Global Domain, rather than the default domain - If the Cloud Provider doesn't explicitly create any domains, then everything exists in the Global Domain. There is no need to specify a domain in any calls, since everything will default to the Global domain. The v2 API will work just fine (which knows nothing about domains) - If they do create some domains, then they indicate (on creation) whether each of these /share/ the namespace of the Global domain, or have their own /private/ namespace. - If all of these new domains were specified as /shared/ then all user and tenant names are still globally unique. A caller still does not technically need to specify a domain, although scoping things down to a domain (or of course project) is likely for most operations (just like it is today) - If, however, some of these new domains were specified as /private/ then any users who are part of a private domain must specify the domain in order to authenticate. By design, authentication will fail if they don't specify a domain (since you won't exist in the global domain). Once a user in a private domain is authenticated, they are scoped to that domain. [implementation: we need to work out whether the domainID is encoded in the token - this is my assumption since this means the Domain Name/ID is NOT required for subsequent requestsand validation, by Keystone, can still be achieved ] - It is perfectly possible (but of course up to the Cloud Provider) to support a mixture of /shared/ and /private/ domains (representing different customer types)but the point being that the Cloud Provider will tell their customers how they should access they system (i.e. provide them with any domain specification that may or may not be required). Very keen to hear other concerns you may have. Henry On 27 Oct 2012, at 21:22, Gabriel Hurley wrote: There are various options for how Horizon can handle the UX problems associated with adding additional domains. Making it a part of the URL is one which could be supported, but I’m not inclined to make that the only method. The implementation details can be hashed out when we get there. I am more concerned about the experience for CLI/API users; adding more parameters they have to pass is quite unfriendly. And I have to say that Keystone’s track record for handling “default” options has been quite poor (see “default tenant”). The mixed support for lookups via ID vs. name is also a mess. There needs to be consistency around what is unique and in what scope (which is where this thread started). So far I haven’t heard a concrete answer on that. For example, if tenants uniqueness is scoped to a domain, and lookups via tenant name are possible, and there’s a default domain… well haven’t you just painted yourself into a corner where tenant names in the default domain must be unique while names in any other domain do not? It’s these kinds of issues that need to really be thought through. -Gabriel *From:*openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net mailto:nebula@lists.launchpad.net]*On Behalf Of*Adam Young *Sent:*Friday, October 26, 2012 4:19 PM *To:*Henry Nash *Cc:*OpenStack Development Mailing List; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net (openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net) *Subject:*Re: [Openstack] [keystone] Domain Name Spaces On 10/26/2012 07:17 PM, Henry Nash
[Openstack] Federated Access To OpenStack
Hi Everyone during the last few weeks we have been working on adding federated access to Open Stack. The basic system is now working in our lab, and clients for nova, swift and glance have been modified in order to allow federated access through a set of federated APIs that we have designed and built. The specifications for the APIs and implementation have been uploaded to DropBox and are available here: http://dl.dropbox.com/u/44986510/Adding%20federated%20access%20to%20OpenStack%201.pdf http://dl.dropbox.com/u/44986510/Client%20Connection%20API%20v1.pdf http://dl.dropbox.com/u/44986510/Federated%20Middleware%20Services-v1.pdf http://dl.dropbox.com/u/44986510/UserGuide.pdf All comments and feedback from the community will be gratefully received. We currently use SAML as the federated access protocol, since a Python library for this already exists, but this can be changed to OpenID OAuth or anything else without changing the specifications or the client implementations (so we hope from the design). Only the federated middleware will need to change, and we can do this once suitable packages become available in Python. We hope to have public demos available by the end of this week, once we can sort out the university firewall and other issues. A use case we have for our federated access is an open source research repository in the cloud for the UK academic community. Since all UK students and staff (up to 1 million people) already have their own university un/pws, they should be able to login to the cloud repository using their existing credentials, in order to store and share their research outputs with others. They should not need to obtain new un/pws in order to access the cloud service. Our federated access to OpenStack provides this functionality. Users who can successfully identify themselves as members of the UK academic community will be automatically enrolled as cloud users and given appropriate tenant IDs. I look forward to having fruitful discussions with you about federated access to OpenStack. regards David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
