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
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
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
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
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
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
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
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?
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
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
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.
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
12 matches
Mail list logo
