Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
This was a concern for HP as well. This is one of the reasons we were happy to see that signed tokens are currently a deployment option. So, you can continue to use the unsigned model until such a time that revocation can be put into place for the token signing model. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Maru Newby Sent: Wednesday, August 01, 2012 7:20 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? Thanks, Maru smime.p7s Description: S/MIME cryptographic signature ___ 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] Identity API v3 - Why allow multi-tenant users?
One benefit is the user does not need to have multiple sets of credentials to interact with multiple projects. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Tuesday, July 17, 2012 11:55 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? On 05/29/2012 01:18 PM, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Did you ever get an answer? This has been discussed in depth. smime.p7s Description: S/MIME cryptographic signature ___ 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] Swift: tempURL
There is a blueprint for this work in Keystone Folsom From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Suchi Sinha (susinha) Sent: Monday, May 14, 2012 11:29 AM To: openstack@lists.launchpad.net Subject: [Openstack] Swift: tempURL I am trying to run swift temp url feature. We have keystone as identity service. Does this feature works with keystone? I am always getting no such file or directory. I am following all the steps generate the tempURL. I will appreciate any help. Thanks. ~Suchi smime.p7s Description: S/MIME cryptographic signature ___ 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] [Swift][Keystone] Swift Quotas
IMHO, if it is a quota related to a tenant or user, then managing it in Keystone makes sense. Jason -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Eoghan Glynn Sent: Friday, May 04, 2012 3:11 AM To: Endre Karlson Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift][Keystone] Swift Quotas Should you mix this into Keystone ? Seems kind of wrong to mix identity manager with Quotas? This was discussed at several sessions the design summit, so I brought it up at the keystone 'state of the nation' session to get a feel for the keystone community's disposition to the idea. There was in-principle agreement that storing such data in the keystone backend is a reasonable approach (well, no strong objections in any case). The idea is that the determining if a user is over-quota is related to authorization in the sense that it determines whether a user normally authorized to consume a resource is allowed to do so in this particular case. From an implementation point, it would also aid greatly in allowing the nova quotas infrastructure to be promoted to openstack-common and hence be reused by other projects such as glance. Cheers, Eoghan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ 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] How many Role name can be used in Keystone and what is the use of each role?
Keystone does not have the concept of least privilege for such operations. The notion of roles with capabilities in Keystone is something that maybe can be addressed in Folsom Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of livemoon Sent: Friday, March 16, 2012 2:46 AM To: openstack@lists.launchpad.net Subject: [Openstack] How many Role name can be used in Keystone and what is the use of each role? I find the roles ( admin, KeystoneAdmin, KeystoneServiceAdmin) are created in devstack. I think each role has it rights to use functions or services. Now I want to know how many roles in keystone can be created and what are use of them . For example, I only want a role only can create/delete users in keystone. How to do it? Thanks -- 非淡薄无以明志，非宁静无以致远 smime.p7s Description: S/MIME cryptographic signature ___ 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 Use Cases and User Stores
http://etherpad.openstack.org/keystone-domains -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, February 17, 2012 12:59 PM To: OpenStack Mailing List Subject: [Openstack] Keystone Use Cases and User Stores Happy Friday (hopefully it's friday when you get this...) As keystone is getting into a new baseline, we're actively going through the bug list and blueprints and re-assessing based on the updated codebase. As we're getting into the details, we want to try and stay as close to the road as possible with implementing features and making sure the features we implement are rock solid going forward. To support that, we are starting to gather use cases of the folks actively deploying and trying to use Keystone. If you're using Keystone, I'd like to encourage you to take a look at the wiki page: http://wiki.openstack.org/KeystoneUseCases and see if there are other use cases that you require for your deployment. With these use cases, and the topics that we are collecting for broader discussion at the Folsom summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics), we are looking to build out blueprints and prioritize work for the upcoming Folsom release. Thanks! -joe (heckj) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ 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 Use Cases and User Stores
Groups are independent of tenants. A role reference can be used to link a group to a tenant, much like it currently links and individual user to a tenant. For example I could give all users in the Nova Basic Admin group the 'netadmin' role for Nova in tenant X. I will not be available on the 28th but Guang can attend. Jason -Original Message- From: Joseph Heck [mailto:he...@mac.com] Sent: Friday, February 17, 2012 1:45 PM To: Rouault, Jason (Cloud Services) Cc: OpenStack Mailing List Subject: Re: [Openstack] Keystone Use Cases and User Stores Thanks Jason - Thats already on our list of topics to discuss more broadly at the Folsom design summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics). The etherpad has a great deal of detail, but I think it needs some conversation needs happen as to how it related to the RBAC discussions that we had the Essex design summit (etherpad at http://etherpad.openstack.org/canhaz). From your user stories, it's not entirely clear what a group concept is getting us that isn't already in tenant when you apply RBAC. I'd like to understand that better. Are you available on IRC to chat sometime? If it would be easier, I'd be happy to schedule it up as a topic of conversation in a future keystone IRC meeting. The next meeting (the 21st - http://wiki.openstack.org/Meetings/KeystoneMeeting), but I've added it to a talk list. Would you be available to chat on IRC on the 28th? -joe On Feb 17, 2012, at 12:28 PM, Rouault, Jason (Cloud Services) wrote: http://etherpad.openstack.org/keystone-domains -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, February 17, 2012 12:59 PM To: OpenStack Mailing List Subject: [Openstack] Keystone Use Cases and User Stores Happy Friday (hopefully it's friday when you get this...) As keystone is getting into a new baseline, we're actively going through the bug list and blueprints and re-assessing based on the updated codebase. As we're getting into the details, we want to try and stay as close to the road as possible with implementing features and making sure the features we implement are rock solid going forward. To support that, we are starting to gather use cases of the folks actively deploying and trying to use Keystone. If you're using Keystone, I'd like to encourage you to take a look at the wiki page: http://wiki.openstack.org/KeystoneUseCases and see if there are other use cases that you require for your deployment. With these use cases, and the topics that we are collecting for broader discussion at the Folsom summit (http://wiki.openstack.org/KeystoneFolsomSummitTopics), we are looking to build out blueprints and prioritize work for the upcoming Folsom release. Thanks! -joe (heckj) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ 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 Swift: swiftauth tenant namespace collisions?
Ziad, I think the problem is that the 'swift' command scopes a user to an account(tenant) via the concatenation of account:username when providing credentials for a valid token. With Keystone and /v2.0 auth the tenantId (or tenantName) are passed in the body of the request. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Friday, November 18, 2011 2:10 PM To: Judd Maltin; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone Swift: swiftauth tenant namespace collisions? Hi Judd - I'm not sire I understand. Can you give me an example of two tenants, their usernames, and the endpoints you would like them to have in Keystone? From: Judd Maltin j...@newgoliath.com Date: Fri, 18 Nov 2011 15:22:09 -0500 To: openstack@lists.launchpad.net Subject: [Openstack] Keystone Swift: swiftauth tenant namespace collisions? In keystone auth for swift (swiftauth), is there a way to eliminate namespace conflicts across tenants? i.e. in tempauth we use account:username password curl -k -v -H 'X-Auth-User: test:tester' -H 'X-Auth-Token: testing' http://127.0.0.1:8080/auth/v1.0 in swiftauth we use username password: $ swift -A http://127.0.0.1:5000/v1.0 -U joeuser -K secrete stat -v StorageURL: http://127.0.0.1:/v1/AUTH_1234 Auth Token: 74ce1b05-e839-43b7-bd76-85ef178726c3 Account: AUTH_12 How can I indicate my tenant (aka account) in this scheme. I already have lots of data. Further, should I create custom endpoint templates for each tenant to address Account: AUTH_12 being unknown to my current swift account db? Thanks very much, -judd -- Judd Maltin T: 917-882-1270 F: 501-694-7809 A loving heart is never wrong. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ 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] [Swift] [Keystone] Account migration
If there is an existing swift customer with swift account 'foo' and nova project 'bar', there is no way to have them belong to the same Keystone tenant. I think that is the data migration issue. Jason -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Tuesday, September 13, 2011 2:49 PM To: John Dickinson Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Thanks, John, for pointing out the uuid thing :). So, let's say I have stored data into a Swift account with a UUID. When I switch to using Keystone, I would like to continue using my old account, since I have a bunch of data in it. However, the account format has changed (under Keystone). So, if I have lazy provisioning on (account_autocreate), would I *accidentally* have 2 Swift accounts instead of one? Ideally, if I can migrate all the old account Ids to use the new format, that would guarantee consistency between the old accounts and any newly-created accounts. Am I missing something here? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 1:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone / Swift integration
Hello, can anyone comment on the status of the Keystone auth middle-ware component for Swift? When can we expect ACL support included? Will we have swauth comparable functionality by the time Diablo releases? Thanks, Jason smime.p7s Description: S/MIME cryptographic signature ___ 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] Nova: Admin API blueprints
Glen, How does one list the servers associated with a particular tenant? When I look at the GET /servers interface it only acts on the account of the 'caller'. Jason From: Glen Campbell [mailto:glen.campb...@rackspace.com] Sent: Tuesday, August 30, 2011 3:46 PM To: Rouault, Jason (Cloud Services); Vishvananda Ishaya; Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Nova: Admin API blueprints We're in the midst of implementing these now: https://blueprints.launchpad.net/nova/+spec/admin-account-actions Essentially suspend/resume for all servers associated with a tenant ID. We're still having discussions around the mass deletion and whether or not we want to expose something that risky (since it's easy enough just to list the servers and delete each one). If we do, it will almost certainly occur after this: https://blueprints.launchpad.net/nova/+spec/deferred-delete-instance From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Tue, 30 Aug 2011 20:56:36 + To: Vishvananda Ishaya vishvana...@gmail.com, Nguyen, Liem Manh liem_m_ngu...@hp.com Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Nova: Admin API blueprints And does that interface exist? Thanks, Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Tuesday, August 30, 2011 12:31 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Nova: Admin API blueprints With keystone in use, there is no user and project object in nova anymore. So the only thing that would make sense inside of nova is: delete all resources associated with a given project_id string. Vish On Aug 30, 2011, at 11:11 AM, Nguyen, Liem Manh wrote: How is Nova project/user deletion handled then? There is no synchronization for that currently. Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. image001.png smime.p7s Description: S/MIME cryptographic signature ___ 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 Identity: Keystone API Proposal
Ziad, What is the expected behavior when requesting and using an unscoped token? Are all possible Service Endpoints returned after authentication based upon the users relationship to various tenants via roles? When the Auth Component validates the token, are all possible roles and Groups across tenants for that user returned? Thanks, Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Thursday, July 21, 2011 12:52 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal Hot, Texas summer regards to all! Since my last note we have had much progress on Keystone. Particularly: * We now have Nova, Dashboard, Glance, and Keystone integration (https://github.com/cloudbuilders/deploy.sh * We've done some work on Swift integration (https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift _auth.py) * LDAP an be your backend (https://github.com/rackspace/keystone/pull/102) * We're incubating! Keystone is now officially an OpenStack Incubation project. * And many other updates, enhanced testing, stability improvements, etc. In my last note I called out our latest API proposal and asked for input. We've received much of that input - thank you - and have four new blueprints to change the API. These are: 1. Support Service Registration (blueprint here https://blueprints.launchpad.net/keystone/+spec/keystone-service-registratio n). 2. Remove support for 'default' tenant. Instead, a 'Member' or 'default' role can be used to manage a default tenant (this may be implemented in the legacy_token_auth front end (blueprint here: https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant). 3. Support for EC2 API and non-password credentials (blueprint here: https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials ). 4. Support for API versioning in the service catalog (blueprint here: https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-supp ort). I'd like to invite comments on those blueprints (here, by email, or on the whiteboards or on the keystone issues list on github. Use the medium you prefer). As well as any new blueprint proposals to change the API. I'd also like to propose a date for locking down the 2.0 API for Diablo. We're going to need some time to finish the implementation by feature freeze (Sept 10th), so I'd like to open the debate up for about three weeks and propose we lock down the API by the end of the weekend of August 14th. Give us your requirements. and let me know if the dates don't work for you or your projects/teams. Best, Ziad From: Ziad Sawalha ziad.sawa...@rackspace.com Date: Fri, 10 Jun 2011 18:24:21 -0500 To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: OpenStack Identity: Keystone API Proposal Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so we can finalize implementation by Diablo-D2 (June 30th). We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here: https://github.com/rackspace/keystone/raw/master/keystone/content/identityde vguide.pdf For any and all interested, the original source and code is on Github (https://github.com/rackspace/keystone https://github.com/rackspace/keystone/raw/master/keystone/content/identityd evguide.pdf ), along with the current implementation of Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at http://launchpad.net/keystone. The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community input, feedback, and participation. Have a great weekend and regards to all, Ziad This email may include confidential information. If you received it in error, please delete it. smime.p7s Description: S/MIME cryptographic signature ___ 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 tenants vs. Nova projects
In typical RBAC systems you specify the role you will be acting in when you gain access. This is the principal of least privilege. Jason From: Yuriy Taraday [mailto:yorik@gmail.com] Sent: Friday, July 15, 2011 11:27 AM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net; Ziad Sawalha; Rouault, Jason (Cloud Services) Subject: Re: [Openstack] Keystone tenants vs. Nova projects Yeah, I agree that we should not duplicate user-tenant link this way. But I cannot understand why should we have anything default. I think, everything should be explicit here. It'll make both code and experience simpler and clearer. So, as I said, user will have to have either some global role or some explicit connection to tenant through role to authenticate in some tenant. Kind regards, Yuriy. On Fri, Jul 15, 2011 at 20:14, Nguyen, Liem Manh liem_m_ngu...@hp.com wrote: Hi Yuriy, The “dual” link concept between user and tenant (user - tenant, and user - role - tenant) is a little bit confusing for me (perhaps, I don’t understand the nuances of it). What happens if a user belongs to a tenant but has no role in it? It seems to me that instead of having a default tenant for a user, we should have a default role for a user instead. With a default role, we can always make sure that the user is authenticated. Regards, Liem From: Yuriy Taraday [mailto:yorik@gmail.com] Sent: Thursday, July 14, 2011 10:37 PM To: openstack@lists.launchpad.net Cc: Ziad Sawalha; Rouault, Jason (Cloud Services); Nguyen, Liem Manh Subject: Re: [Openstack] Keystone tenants vs. Nova projects I think, there should not be such thing as default tenant. If user does not specify tenant in authentication data, ones token should not be bound to any tenant, and user should have access to resources based on global role assignments. If user specify tenant, one should be either explicitly bound to tenant (probably through UserRoleAssignment model, but it is not the best way) or in some global role. Then one will have access to resources based on global role assignments and tenant role assignments. I'm not sure whether users should be added to a tenant and then to roles in this tenant or we should remove totally direct link between user and tenant, so that user is in tenant if and only if one is in any role in this tenant. Kind regards, Yuriy. On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh liem_m_ngu...@hp.com wrote: When one creates a user, should a user always have a tenant associated with her? If that’s the case, then the “default” tenant is the tenant that the user is associated with at creation time? Sorry for responding to the question with another question, but it is unclear for me from looking at the model (there is no non-null constraint on the tenant_id fk on the user table). Thanks, Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen mailto:openstack-bounces%2Bliem_m_nguyen =hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Thursday, July 14, 2011 12:22 PM To: Rouault, Jason (Cloud Services); Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects In the example I gave below they are not members of any group and have no roles assigned to them. Should they still be authenticated? From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Thu, 14 Jul 2011 16:25:22 + To: Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: RE: [Openstack] Keystone tenants vs. Nova projects A user can specify a tenantID at the time of authentication. If no tenantID is specified during authentication, then I would expect the ‘default’ tenant for the user would apply. The capabilities of User1 on TenantA (in this case the default tenant for the user) would be determined by their role and group assignments within the context of TenantA. Jason From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: Wednesday, July 13, 2011 10:35 PM To: Rouault, Jason (Cloud Services); Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects What if: - User1 has TenantA as her default tenant Should the service authenticate the user against TenantA? And if so, why? What does the 'default tenant' grant User1 on TenantA? It's some nebulous, implied role… From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Wed, 13 Jul 2011 13:18:44 + To: Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: RE: [Openstack] Keystone tenants vs. Nova projects If a user is bound to their default tenant, why wouldn’t any role assignments for that user in their default tenant
Re: [Openstack] Keystone tenants vs. Nova projects
A user can specify a tenantID at the time of authentication. If no tenantID is specified during authentication, then I would expect the 'default' tenant for the user would apply. The capabilities of User1 on TenantA (in this case the default tenant for the user) would be determined by their role and group assignments within the context of TenantA. Jason From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: Wednesday, July 13, 2011 10:35 PM To: Rouault, Jason (Cloud Services); Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects What if: - User1 has TenantA as her default tenant Should the service authenticate the user against TenantA? And if so, why? What does the 'default tenant' grant User1 on TenantA? It's some nebulous, implied role. From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Wed, 13 Jul 2011 13:18:44 + To: Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: RE: [Openstack] Keystone tenants vs. Nova projects If a user is bound to their default tenant, why wouldn't any role assignments for that user in their default tenant apply? User1 authenticates specifying TenantB, this binds User1 into the context of TenantB. In subsequent web service requests using the token received after authentication, the Auth component filter would decorate the headers with RoleY. If User1 authenticates specifying TenantA, or specifying no Tenant, this binds User1 into the context of TenantA. The headers would then be decorated with RoleX. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Tuesday, July 12, 2011 10:09 PM To: Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects Our goal is to support Nova use cases right now. You can provide access to multiple tenants using a role assignment (assigning a user a role on a specific tenant effectively binds them to that tenant). However, this raises the issue of what the 'implied' role of a user is when they are bound to their default tenant. So we're considering how to alter the model to clean that up. No great solution yet. Any suggestions are welcome.. Ziad From: Yuriy Taraday yorik@gmail.com Date: Tue, 28 Jun 2011 16:59:08 +0400 To: openstack@lists.launchpad.net Subject: [Openstack] Keystone tenants vs. Nova projects Currently Keystone model assumes that user is bound to exactly one tenant. It conflicts with the fact that in Nova user can have access to several projects. Which way will it be? Kind regards, Yuriy. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. This email may include confidential information. If you received it in error, please delete it. smime.p7s Description: S/MIME cryptographic signature ___ 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 tenants vs. Nova projects
Yes, you always authenticate. If the user has no roles or group then would have no access rights to do anything. However, this would be an unusual case, as I would expect users to be automatically added a user group or developer role when their account was created. Jason From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: Thursday, July 14, 2011 1:22 PM To: Rouault, Jason (Cloud Services); Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects In the example I gave below they are not members of any group and have no roles assigned to them. Should they still be authenticated? From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Thu, 14 Jul 2011 16:25:22 + To: Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: RE: [Openstack] Keystone tenants vs. Nova projects A user can specify a tenantID at the time of authentication. If no tenantID is specified during authentication, then I would expect the 'default' tenant for the user would apply. The capabilities of User1 on TenantA (in this case the default tenant for the user) would be determined by their role and group assignments within the context of TenantA. Jason From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: Wednesday, July 13, 2011 10:35 PM To: Rouault, Jason (Cloud Services); Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects What if: - User1 has TenantA as her default tenant Should the service authenticate the user against TenantA? And if so, why? What does the 'default tenant' grant User1 on TenantA? It's some nebulous, implied role. From: Rouault, Jason (Cloud Services) jason.roua...@hp.com Date: Wed, 13 Jul 2011 13:18:44 + To: Ziad Sawalha ziad.sawa...@rackspace.com, Yuriy Taraday yorik@gmail.com, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: RE: [Openstack] Keystone tenants vs. Nova projects If a user is bound to their default tenant, why wouldn't any role assignments for that user in their default tenant apply? User1 authenticates specifying TenantB, this binds User1 into the context of TenantB. In subsequent web service requests using the token received after authentication, the Auth component filter would decorate the headers with RoleY. If User1 authenticates specifying TenantA, or specifying no Tenant, this binds User1 into the context of TenantA. The headers would then be decorated with RoleX. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Tuesday, July 12, 2011 10:09 PM To: Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects Our goal is to support Nova use cases right now. You can provide access to multiple tenants using a role assignment (assigning a user a role on a specific tenant effectively binds them to that tenant). However, this raises the issue of what the 'implied' role of a user is when they are bound to their default tenant. So we're considering how to alter the model to clean that up. No great solution yet. Any suggestions are welcome.. Ziad From: Yuriy Taraday yorik@gmail.com Date: Tue, 28 Jun 2011 16:59:08 +0400 To: openstack@lists.launchpad.net Subject: [Openstack] Keystone tenants vs. Nova projects Currently Keystone model assumes that user is bound to exactly one tenant. It conflicts with the fact that in Nova user can have access to several projects. Which way will it be? Kind regards, Yuriy. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. This email may include confidential information. If you received it in error, please delete it. This email may include confidential information. If you received it in error, please delete it. smime.p7s Description: S/MIME cryptographic signature ___ 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 tenants vs. Nova projects
If a user is bound to their default tenant, why wouldn't any role assignments for that user in their default tenant apply? Here is how I thought things were to work: - User1 has TenantA as her default tenant - User1 has been assigned RoleX for TenantA - User1 has also been assigned RoleY for TenantB User1 authenticates specifying TenantB, this binds User1 into the context of TenantB. In subsequent web service requests using the token received after authentication, the Auth component filter would decorate the headers with RoleY. If User1 authenticates specifying TenantA, or specifying no Tenant, this binds User1 into the context of TenantA. The headers would then be decorated with RoleX. Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Tuesday, July 12, 2011 10:09 PM To: Yuriy Taraday; openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone tenants vs. Nova projects Our goal is to support Nova use cases right now. You can provide access to multiple tenants using a role assignment (assigning a user a role on a specific tenant effectively binds them to that tenant). However, this raises the issue of what the 'implied' role of a user is when they are bound to their default tenant. So we're considering how to alter the model to clean that up. No great solution yet. Any suggestions are welcome.. Ziad From: Yuriy Taraday yorik@gmail.com Date: Tue, 28 Jun 2011 16:59:08 +0400 To: openstack@lists.launchpad.net Subject: [Openstack] Keystone tenants vs. Nova projects Currently Keystone model assumes that user is bound to exactly one tenant. It conflicts with the fact that in Nova user can have access to several projects. Which way will it be? Kind regards, Yuriy. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. smime.p7s Description: S/MIME cryptographic signature ___ 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 Identity: Keystone API Proposal
See inline. Jason From: andi abes [mailto:andi.a...@gmail.com] Sent: Wednesday, June 15, 2011 5:04 PM To: Rouault, Jason (Cloud Services) Cc: Ziad Sawalha; openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal Jason, Sounds like the model you're proposing could be achieved by something like this: On Keystone: - Roles are identified by name and contain tuples in the form of: -- the service to which this permission applies (e.g. service nova, swift). Including the service is meant to side track attempts to normalize actions across very different types of services -- the type of target this action applies to - e.g. volume, network port etc. -- action this permission allows - e.g. start vm, create volume. - An authorize API call which accepts: - the service requesting the authorization - user token (from a previous authentication) - tenant ID (to resolve the realm of the user token) - a target type - the attempted action. This API would lookup the token, and if its present combine a set of the relevant permissions from all the roles the token is referencing. If the requested tuple exists in this combine set, the request is authorized. A few caveats remain: a) the above description doesn't include Resource Groups... as Ziad mentioned, that is currently differed. When those are introduced, the service should probably pass the instance-id of the target, and Keystone would have to take that into account. JLR I think there are a number of ways to account for this if we leveraged a hierarchical (URI) structure and allowed for wild carding. b) the current API's in keystone allows a service to perform actions on multiple instances across tenants (containers) efficiently - a service could obtain a list of accessible tenants and cache it. If only the 'authorize' API is available, the service would need to perform a check with keystone for every instance JLR Please explain the model for Tenant, Accounts, Projects, Groups, Roles.. I have not been able to discern how tenant will map to accounts and projects. In any case, there are things that can be done to improve the potential overhead of authorization calls. however, you will not eliminate it completely. That is the price you pay for increased security. If authorization is pluggable, operators can determine if and how they want to use it. c) In this model it is required to populate role definitions into keystone, for all services. Since keystone should be independent of other services, the set of actions/targets should probably be considered as data for it - requiring a deployment step of sorts to make keystone aware of these roles. This could be avoided if the authorization decision is looked at as 2 separate steps: 1. figure out what roles a user posses. 2. expand the set of roles to set of actions allowed 3. determine if the action attempted is allowed JLR Each service would need to document its target structure and actions (this would be very similar to their published API's). I think there would be a default set of roles and permissions pre-populated to satisfy the base set of use cases. it is obviously debatable where keystone ends and the services begin. In the model above, keystone is responsible for all 3 steps via the authorize API. I *think* the current API provides a very similar model, with the line drawn at 1 - i.e. keystone provides to roles, and there is a separate middleware piece to perform 2 3, executing in the request pipleline of the service. Where this middleware executes (i.e. what is the API boundary to keystone) doesn't necessarily change the overall model. JLR Without a pluggable authorization system, operators will never be able to provide fine-grained access control without mucking with hardcoding in the API layer. That is not a good path I *think*. On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services) jason.roua...@hp.com wrote: In my opinion the services (and their developers) should not need to interpret roles thus resulting in varying semantics. Roles should be defined by a set of configurable privileges to perform certain actions on specific targets for particular services. The API should only need to know to check with an authorization subsystem whether the incoming request is allowed based on the who is making the request and the 3-tuple mentioned previously. Jason From: andi abes [mailto:andi.a...@gmail.com] Sent: Wednesday, June 15, 2011 9:18 AM To: Rouault, Jason (Cloud Services) Cc: Ziad Sawalha; openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal I would expect that the API of each service would have to interpret the role assigned to a user in the context of that service - roles for swift nova glance quantum etc would probably carry very different semantics. So, to my
Re: [Openstack] OpenStack Identity: Keystone API Proposal
Is there a plan to also have Keystone be the centralizing framework around authorization? Right now it looks like policy enforcement is left to the API layer. Thanks, Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Friday, June 10, 2011 5:24 PM To: openstack@lists.launchpad.net Subject: [Openstack] OpenStack Identity: Keystone API Proposal Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so we can finalize implementation by Diablo-D2 (June 30th). We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here: https://github.com/rackspace/keystone/raw/master/keystone/content/identityde vguide.pdf For any and all interested, the original source and code is on Github (https://github.com/rackspace/keystone https://github.com/rackspace/keystone/raw/master/keystone/content/identityd evguide.pdf ), along with the current implementation of Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at http://launchpad.net/keystone. The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community input, feedback, and participation. Have a great weekend and regards to all, Ziad Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
