I wanted to throw in my two cents here. I generally agree with the
notion that we should have the ability to issue tokens with different
scopes. And that this will become increasingly useful down the road
as we seek to provide finer grained access control for each user.
Having said this, I do hav
I'm okay with "Starting Tokens".
-jOrGe W.
On Oct 23, 2012, at 7:25 AM, Adam Young wrote:
On 10/23/2012 01:25 AM, 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
: [openstack-dev] [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API
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
On 10/23/2012 01:25 AM, 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. Curre
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
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 scope
+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 b
On Oct 21, 2012 12:11 PM, "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 acco
+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 t
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 mailto:he...@mac.com>>
*Subject: **[openstack-dev] [keystone] Tokens represent
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
> Subject: [openstack-dev] [keystone] Tokens representing authorization to
> projects/tenants in the Keystone V3 API
11 matches
Mail list logo
