data in it.
This allows us to plug pam/sssd in as well. Those will be Identity only.
On 05/21/2013 06:18 AM, David Chadwick wrote:
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
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
special
et to add that I expect one (central) user
store.
Thanks
Pat
On Mon, 18 Feb 2013 16:11:05 +0000, 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 Key
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 custom
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 ou
scoped to multiple tenants.
- joe
On Nov 13, 2012, at 9:17 AM, David Chadwick
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 Keystone for i
n
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
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
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?
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. Ot
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 mailto:dolph.math...@gmail.com>> wrote:
I think this discussion would be great for both mailing lists.
-Dolph
On Fri, Oct 26, 2012 at 5:18
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 etc
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
a
13 matches
Mail list logo
