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
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
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
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
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
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
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
://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
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
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
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
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
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
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
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:
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
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,
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:
18 matches
Mail list logo
