Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?
A service can have 0 to N endpoints. Why not? To the end users, what's the difference between no endpoints and unreachable endpoints anyway. It should be up to the client to return a more human-readable, actionable error message. An endpoint is basically consisted of an URI and a bunch of characteristics/attributes about that URI right? Question is which characteristics should be core and which characteristic are vendor/deployment-specific. As Liem mentioned, the schema does allow vendors to add arbitrary attributes to the endpoints with having to use meta data. Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Wednesday, April 25, 2012 10:14 AM To: Joseph Heck Cc: Adam Gandelman; openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? From: Joseph Heck [mailto:he...@me.com] Sent: Wednesday, April 25, 2012 9:47 AM To: Nguyen, Liem Manh Cc: Joe Savak; openstack@lists.launchpad.net (openstack@lists.launchpad.net); Adam Gandelman Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? This isn't about parsing the data structure - it's about what a "service" represents so that we can model it appropriately. So what does the "service" here represent? the collection of all possible services of that type? That's what your example would seem to indicate. In your example, the service is a pretty simple structure - just having a type (driven by convention and API spec) and human readable name, and each service is expected to have 1 to N endpoints. Is it reasonable to have a service without any endpoints? Regardless of reasonable, is it allowable? > Liem: Will we ever have a service that has no endpoints? With no way to contact the service, can one utilize the service? If we answer no to those questions, then I think we should have service 0..* <-> 1..* endpoint. Also, can an endpoint have more than 1 services? I think yes, because service is just a logical concept, and endpoint API may decide to support multiple services (for billing or whatever)... What does an endpoint represent? The API's URI point, clearly. Is there a uniqueness constraint of any kind on endpoints? Is it allowable (if strange) to list 3 duplicate endpoints with exactly the same metadata on it? > Liem: I like the fact that we are not enforcing unique constraints on endpoints; so, services have the freedom to define what is needed. -joe On Apr 25, 2012, at 9:37 AM, Nguyen, Liem Manh wrote: I would like to keep the service type and name under the service and not the endpoint, too. Make it easier to parse for a given service. One thing is that I am not sure if we need the metadata tag. In the Keystone XSD, we have the construct , which allows any additional, implementation-specific attribute to be added. Those that do not support the specific attribute can simply ignore it. A couple of benefits I can see with not using the metadata tag, and just use the custom element directly like this: http://paste.openstack.org/show/13832/, which the anyAttribute supports, are: . Simplier parsing, one level less. . If that attribute becomes a core attribute later, no need to change the parser. Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Joe Savak Sent: Tuesday, April 24, 2012 1:04 PM To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? Having endpoints under the service construct is supposed to make it easier to programmatically find the endpoint(s) you are interested in. For example - as nova client I can parse the service catalog and identity nova by service-type "compute" in order to get the public, internal, and admin endpoints for nova. By having service type & name as attributes under the endpoint, I'll have a harder time doing that (having to dive into each endpoint construct to identify the ones with service-type "compute"). Maybe it would be better to have each endpoint have its own construct inside of a service. So instead of http://paste.openstack.org/show/13678/ Maybe http://paste.openstack.org/show/13682/ From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, April 20, 2012 4:16 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints? While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current "service" and
Re: [Openstack] Keystone client, user belongs to many tenants?
I think this use case underscores one of the key differences between the fat
Keystone (Diablo - E3) and KSL (Essex final). In fat Keystone, users and
tenants are loosely coupled. They are bind together by role assignments. In
KSL, users and tenants are tightly coupled, and IMHO very inflexible. Maybe the
following example would further clarify this …
Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, roles
Commissioner and Minority Owner, and service MLB. And you want Bud Selid to
have the Commissioner role for Dodgers, Giants, and Brewers, but Minority Owner
role for Brewers only.
In fat Keystone, there a couple of ways you can accomplish this.
1) Make Commissioner a “global role” (unscoped) and assign it to user Bud
Selid. Assign the Minority Owner role to Bud Selid for tenant Brewers by
creating a role reference. When Bud Selid tries to access MLB with his unscoped
token, MLB will get his Commissioner role back from Keystone. When Bud Selid
tries to access MLB with his token scoped to Brewers, MLB will get both his
Commissioner and Minority Owner roles back from Keystone. When Bud Selid tries
to acess MLB with his token scoped to Giants or Dodgers, MLB will only get his
Commissioner role back from Keystone.
2) Assign the Commissioner role to Bud Selid to tenants Giants, Dodgers,
and Brewers individually by creating the respective role references. Assign the
Minority Owner role to Bud Selid for tenant Brewers by creating another role
reference. In this scenario, Bud Selid will always need a scoped token to
access MLB.
In KSL, there really aren’t any effective ways to accomplish the same thing.
Global roles are no longer supported. A given user must assign to exactly one
tenant. I suppose you can have Bud Selid under the “Default Tenant”, and assign
both Commissioner and Minority Owner roles to him. But there are two major side
effects.
1) Bud Selid must access MLB with the token scoped to the “Default Tenant”
in order for MLB to recognize him as Commissioner. Which means he IS ALSO the
Minority Owner for Dodgers, Giants, and Brewers. J
2) If Bud Selid tries to access MLB with the token scoped to either
Giants, Dodgers, or Brewers, his a NOBODY. J
The upcoming Domains blueprint (to be implemented for Folsom), which offers
true multitenancy, should support these types of use cases.
https://blueprints.launchpad.net/keystone/+spec/keystone-domains
With Domains, you can create a MLB domain with tenants Dodgers, Giants, and
Brewers. And have Bud Selid under the MLB domain. Notice that users will no
longer be assigned to tenants. They will be under a domain. Create roles
Commissioner and Minority Owner in the MLB domain. Assign the Commissioner role
to Bud Selid, and the Minority Owner role scoped to Brewers. Suppose you have
another domain NFL, Bud Selid will not be able to access any tenants in the NFL
domain, unless the NFL domain administrator explicitly assign NFL roles to Bud
Selid.
Guang
From: openstack-bounces+guang.yee=hp@lists.launchpad.net
[mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of
Dolph Mathews
Sent: Wednesday, May 09, 2012 4:34 PM
To: Joshua Harlow
Cc: openstack
Subject: Re: [Openstack] Keystone client, user belongs to many tenants?
The user create command is actually creating discrete users, each with a
"default tenant" reference.
While that's fine for a lot of simple use cases, it doesn't directly support a
user accessing multiple tenants at all.
Instead, create a role, and grant that role to a user-tenant pair, creating an
explicit relationship between the two. Using default tenants is optional with
this method, but will affect how users must auth.
-Dolph Mathews
On May 9, 2012, at 3:46 PM, Joshua Harlow wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am trying
to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, "Duplicate entry 'admin' for key 'name'") 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{"password":
"$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/",
"enabled": true, "email": "ad...@example.com", "tenantId":
"d1506184877a449a91fc6adcb553ad97"}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much info
also (hashed password??) :-P
Any ideas?
___
Mailing list: https://launchpad.net/~openstack
[Openstack] Keystone: is revoke token API "officially" supported
I see it implemented in the code as
DELETE /v2.0/tokens/{tokenId}
But it doesn't appear to be documented in any of the WADLs.
Thanks!
Guang
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] Capture of the Keystone/LDAP Role discussion
Sorry I am a little late to this thread. " When we talk about Roles, we mean the permissions a given user has in a given tenant. As such, it is a three way relationship, and LDAP does not handle those well." Have we also consider services and global roles? There was security bug regarding tenant role conflicts/overlaps. https://bugs.launchpad.net/keystone/+bug/890411 How are they being handled in your LDAP design? Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Thursday, February 02, 2012 12:55 PM To: Ryan Lane; openstack@lists.launchpad.net Subject: Re: [Openstack] Capture of the Keystone/LDAP Role discussion On 02/02/2012 11:50 AM, Ryan Lane wrote: >> Based on discussions with numerous people, It seems that the subtree >> approach (as done by nova deprecated) is the norm. >> > It's a normal approach taken by a number of applications, yes. It's > not a bad way to handle this, and we are already doing it in nova. The > plus of doing it this way, rather than key-value pairs on users, is > that when a tenant is deleted, all of the roles are deleted with it. > Also, referential integrity plugins can remove userdns from tenants > and roles when a user is deleted. > > It'll still be necessary for admins to remove users from roles when > removed from tenants, and we can't depend on that, so we should handle > that case. I'll make sure that gets in. > >> What seems to vary the most amongst LDAP servers is not the schema, but the >> method used to query for membership in nested groups. In OpenLDAP, the >> syntax involves sets >> >> http://www.openldap.org/faq/data/cache/1133.html >> http://www.openldap.org/faq/data/cache/1134.html >> >> Whereas in Active directory, it involves using LDAP_MATCHING_RULE_IN_CHAIN >> rule OID. >> >> In the 389 (Fedora) Directory Server as well as OpenLDAP it is also possible >> to use the deference control in conjunction with the memberof plugin. >> >> >> However, we might not need to query for nested group membership. For >> example, lets assume a tenant has 3 administrative roles: user management, >> network management, VM management. In addition, users that do not have an >> explicit admin role get read only access to the resources of that tenant. >> So a user that has the right to manage networks for that tenant would have >> to appear in both the members list of that tenant as well as in the >> networkMgmt role. The first is provided for read only access, and the >> second for the ability to modify the network. It is a little redundant. We >> could perhaps put a constraint on the roles that they will only allow users >> that are listed in the general membership for that tenancy. >> > It shouldn't be necessary to do nested searching. When searching for > tenant roles for a user, it should be enough to search for the user as > a member of roles using the tenant as a base. > > Even if nested group searching is necessary, it's possible to do > nested searching without support for it on the LDAP server side. A > recursive search works here. memberOf is also a possibility, but it > needs to be supported on the server side; also, some servers use > memberOf, and some use isMemberOf, so we'd have to make that > configurable. > > It's likely best to assume some server in use won't support plugins or > extensions. We can discover capabilities from the server and use a > more efficient method if it's available, while falling back to the > less efficient method. Short-lived caches of the results can also > alleviate performance problems due to inefficient queries. Right. First step is getting something to function, and then we can performance tune. > >> There was some talk about nesting tenancies for resellers. This is somewhat >> different from nested group member ship, as entry in the lower level tenant >> should *not* provide access to all resources of the containing tenancy. >> Permissions go the other way around: if I am an admin of the container, I >> can manage elements of the contained. It does mean that the Keystone server >> needs to be smart enough to check all of the levels of nesting from lowest >> to highest to see if a user has the appropriate role for the requested >> operation. >> >> So, to summarize: Roles will be entites under tenants, with a member >> field that indicates the users that have that role. >> >> > We still need some way to differentiate between roles and tenants, > otherwise subtree searches will cause problems. > > In nova we handled this by assigning the owner attribute on tenants, > but no owner on roles. This allowed tenants to be found via a search > like this: > >(&(objectclass=groupofnames)(owner=*)) > > Roles are then discovered by a search like this, using the tenant as a base: > >(objectclass=groupofnames) > > Alternatively, we could add schema for roles and pr
Re: [Openstack] "Admin"-ness in Keystone, Nova, et. al.
Does this look familiar? J https://bugs.launchpad.net/keystone/+bug/890411 Guang From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Andy Smith Sent: Friday, March 30, 2012 10:27 AM To: Julien Danjou Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] "Admin"-ness in Keystone, Nova, et. al. Commented on the first bug. On Fri, Mar 30, 2012 at 7:41 AM, Julien Danjou wrote: On Fri, Mar 30 2012, Gabriel Hurley wrote: > In practice today, Keystone no longer has global roles, and RBAC > implementation isn't fully there yet across the ecosystem. So projects have > adopted inconsistent means of determining when and how to grant > "admin"-level privileges to that user. This isn't something individual > projects can decide, though. It has to be agreed upon and consistent. > > I don't have a great solution for this problem since it's so very late in > the Essex release cycle. However, I'm hoping we can perhaps do *something* > other than to simply document that "users with admin-level permissions > should only ever be granted admin permissions on a single admin tenant, and > no other users should be granted an admin role anywhere." > > All that said, I'm deeply concerned about the security implications of > real deployments being unaware of the unintended consequences of > granting what appears to be a scoped "admin" role. Correct me if I'm wrong, but it seems to me that the problem is simply that the default policy used in keystone and nova says that "admin is anybody with role `admin' on any tenant", as you can see in their respective policy.json files. I think that this rule should probably be set to something else by default, like the user is admin if "it has role admin on a specific tenant (like a tenant named `admin')". Tthat would allow to emulate the old "global" admin role, just by using a specific tenant. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] "Admin"-ness in Keystone, Nova, et. al.
I think the fat Keystone implemented this naming hack. But why place a constraint on the names (i.e. may not be i18n friend) where we can do it right at once? Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Friday, March 30, 2012 11:33 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] "Admin"-ness in Keystone, Nova, et. al. FWIW, it is possible in Glance to set the configuration option admin_role value to something other than "admin" -- for instance "glance:admin" -- to use a different role than "admin" to indicate a role that should only be able to admin Glance and not other endpoints. https://github.com/openstack/glance/blob/master/etc/glance-api.conf#L33 Perhaps an immediate "solution" to this bug/feature request would be to add similar functionality to Keystone, Nova and Quantum? Best, -jay On 03/30/2012 02:10 PM, Yee, Guang wrote: > Does this look familiar? J > > https://bugs.launchpad.net/keystone/+bug/890411 > > Guang > > *From:*openstack-bounces+guang.yee=hp@lists.launchpad.net > [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] *On > Behalf Of *Andy Smith > *Sent:* Friday, March 30, 2012 10:27 AM > *To:* Julien Danjou > *Cc:* openstack@lists.launchpad.net > *Subject:* Re: [Openstack] "Admin"-ness in Keystone, Nova, etc > > Commented on the first bug. > > On Fri, Mar 30, 2012 at 7:41 AM, Julien Danjou > mailto:julien.dan...@enovance.com>> wrote: > > On Fri, Mar 30 2012, Gabriel Hurley wrote: > > > In practice today, Keystone no longer has global roles, and RBAC > > implementation isn't fully there yet across the ecosystem. So > projects have > > adopted inconsistent means of determining when and how to grant > > "admin"-level privileges to that user. This isn't something individual > > projects can decide, though. It has to be agreed upon and consistent. > > > > I don't have a great solution for this problem since it's so very late in > > the Essex release cycle. However, I'm hoping we can perhaps do > *something* > > other than to simply document that "users with admin-level permissions > > should only ever be granted admin permissions on a single admin > tenant, and > > no other users should be granted an admin role anywhere." > > > > All that said, I'm deeply concerned about the security implications of > > real deployments being unaware of the unintended consequences of > > granting what appears to be a scoped "admin" role. > > Correct me if I'm wrong, but it seems to me that the problem is simply > that the default policy used in keystone and nova says that "admin is > anybody with role `admin' on any tenant", as you can see in their > respective policy.json files. > > I think that this rule should probably be set to something else by > default, like the user is admin if "it has role admin on a specific > tenant (like a tenant named `admin')". Tthat would allow to emulate the > old "global" admin role, just by using a specific tenant. > > -- > Julien Danjou > // eNovance http://enovance.com > // ✉julien.dan...@enovance.com <mailto:julien.dan...@enovance.com> ☎+33 > 1 49 70 99 81 > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > <mailto: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 ___ 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] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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. There's a blueprint to address the need to scope the token down to the service or endpoint level. Basically, service and endpoint isolation. 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 of scoping a single token to multiple >>> tenants / endpo
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Is "belongsTo" mandatory? If not, what will token validation API return?
{"access": [list of tokens]}
?
Guang
-Original Message-
From: Jorge Williams [mailto:jorge.willi...@rackspace.com]
Sent: Wednesday, November 14, 2012 2:47 PM
To: OpenStack Development Mailing List
Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
Subject: Re: [openstack-dev] [Openstack] Fwd: [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API
>From an API perspective the changes required are the following:
1. The validate call returns a list of tenants instead of a single
tenant.
If the tenant id is in the URI of the API, then the validation middleware
can assert that the tenant id is in the list of IDs.
Not sure if there's any additional changes, but I don't think so.
An alternative approach is to use the belongsTo query parameter in the
validate call. So if you know the tenantId of the resource, you can issue a
validate with ?belongsTo="tenatId" and validation if the tenant is not in
the list of tenatIds for the token. The belongsTo query parameter is in the
validate token call in the API today
http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_val
idateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1
356.html
And we use it quite a bit in our implementation, when we validate tokens --
that is in the case where a token may have access to multiple tenants.
Thoughts?
-jOrGe W.
On Nov 14, 2012, at 3:53 PM, heckj wrote:
> If we're going to assert it's supported, we're doing an incredible
dis-service to writing a spec to not implement that aspect of the spec, as
that kind of set up just leads to incompatibilities and confusion when
asserting how the spec should be used to provide interoperability.
>
> If we accept this as a spec addition, then we MUST have an implementation
that makes it clear how we expect to interoperate with that aspect of the
specification, even if it's a configuration option that we don't normally
enable. If we don't test and validate it to prove interoperability, then the
spec is a worthless digital "piece of paper".
>
> So under that pretext, I welcome suggestions on how to interpret the spec
you're proposing to some concrete implementations that can be verified for
interoperability, and that are compatible with the existing and/or upcoming
implementations for V3 API.
>
> -joe
>
> On Nov 14, 2012, at 1:35 PM, Joe Savak wrote:
>> Hi Joe,
>> If I'm working across multiple tenants, I'd prefer one token that I
can securely handle that proves access rights to the tenants I'm working
with. Handling multiple tokens increases the complexity of clients needing
to provide multi-tenancy access to an authenticated identity. It also adds
more calls to keystone.
>>
>> Again, I think that having the keystone reference implementation restrict
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in
the API contract though. It needs to be extensible and flexible to allow for
the all sorts of use cases that are likely to occur.
>>
>> Thanks,
>> joe
>>
>> -Original Message-
>> From: heckj [mailto:he...@mac.com]
>> Sent: Tuesday, November 13, 2012 3:59 PM
>> To: Joe Savak
>> Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
representing authorization to projects/tenants in the Keystone V3 API
>>
>> Hey Joe:
>>
>> Currently a user scoped token doesn't include a service catalog - mostly
because I think the service catalog generally requires tenant_id's to
interpolate into the values to provide it. That doesn't mean we can't put
in/include service catalog endpoints where that value doesn't need to be
determined.
>>
>> I'm also questioning the value of providing a token scoped to all tenants
associated with a user - that seems to have the same value as just using a
user token.
>>
>> In fact, even if we allow some arbitrary set of tenants to be scoped into
a token along with a user, what on earth should be in the service catalog?
Endpoints relevant to every possible tenant?
>>
>> This just seems to be a potential explosion of data that is poorly scoped
from a security perspective.
>>
>> -joe
>>
>> On Nov 13, 2012, at 1:42 PM, Joe Savak wrote:
>>> Will user-scoped token include the full service catalog?
>>>
>>> Also, I thought the consensus was to allow the API contract to be
flexible on how many tenants we can scope the token to. The ref impl can
enforce 1 tenant-scoped token. Are we diverging from this?
>>>
>>> Thanks,
>>> joe
>>>
>>> -Original Message-
>>> From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of heckj
>>> Sent: Tuesday, November 13, 2012 1:34 PM
>>> To: OpenStack Development Mailing List
>>> Cc: openstack@lists.lau
Re: [Openstack] [keystone] Encryption based user authentication in keystone
Only password and token authentications are natively supported (by default) at the moment. There are also signature-based authentication APIs like ec2 and s3 available as extensions. Other mechanisms such as two-way SSL and external authentication via a web frontend is also possible? In v3, we should like to introduce authn plugin capability as well. Do you want to share your use case so we can discuss possible solutions? Guang -Original Message- From: openstack-bounces+guang.yee=hp@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of Koert van der Veer Sent: Monday, January 28, 2013 1:36 AM To: openstack@lists.launchpad.net Subject: [Openstack] [keystone] Encryption based user authentication in keystone I vaguely remember some chatter on the last summit about using something other than passwords for user authentication in keystone. However, looking at the sourcecode and blueprints I can't seem to find this feature. I see a lot of encryption-based in tokens, but not between the end-user and keystone. Are there any plans in that direction, or should I be rolling my own solution? 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] Policy settings not working correctly
I think keystone client is still V2 by default, which is enforcing
admin_required.
Try this
"admin_required": [["role:KeystoneAdmin"], ["role:admin"], ["is_admin:1"]],
Guang
From: Openstack
[mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of
Adam Young
Sent: Thursday, June 06, 2013 7:28 PM
To: Heiko Krämer; openstack
Subject: Re: [Openstack] [Keystone] Policy settings not working correctly
What is the actualy question here? Is it "why is this failing" or "why was
it done that way?"
On 06/04/2013 07:47 AM, Heiko Krämer wrote:
Heyho guys :)
I've a little problem with policy settings in keystone. I've create a new
rule in my policy-file and restarts keystone but keystone i don't have
privileges.
What is the rule?
Example:
keystone user-create --name kadmin --pw lala
keystone user-role-add --
keystone role-list --user kadmin --role KeystoneAdmin --tenant admin
+--+--+
|id| name |
+--+--+
| 3f5c0af585db46aeaec49da28900de28 |KeystoneAdmin |
| dccfed0bd790420bbf1982686cbf7e31 | KeystoneServiceAdmin |
cat /etc/keystone/policy.json
{
"admin_required": [["role:admin"], ["is_admin:1"]],
"owner" : [["user_id:%(user_id)s"]],
"admin_or_owner": [["rule:admin_required"], ["rule:owner"]],
"admin_or_kadmin": [["rule:admin_required"], ["role:KeystoneAdmin"]],
"default": [["rule:admin_required"]],
[.]
"identity:list_users": [["rule:admin_or_kadmin"]],
[]
keystone user-list
Unable to communicate with identity service: {"error": {"message": "You are
not authorized to perform the requested action: admin_required", "code":
403, "title": "Not Authorized"}}. (HTTP 403)
In log file i see:
DEBUG [keystone.policy.backends.rules] enforce admin_required: {'tenant_id':
u'b33bf3927d4e449a98cec4a883148110', 'user_id':
u'46a6a9e429db483f8346f0259e99d6a5', u'roles': [u'KeystoneAdmin']}
Why does keystone enforce admin_required rule instead of the defined rule
(admin_or_kadmin).
Historical reasons. We are trying to clean this up.
Keystone conf:
[...]
# Path to your policy definition containing identity actions
policy_file = policy.json
[..]
[policy]
driver = keystone.policy.backends.rules.Policy
Any have an idea ?
Thx and greetings
Heiko
___
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
