Hi Jamie
In my opinion no security token should have the potential to last
forever. This is a bad idea and can lead to all sorts of security
vulnerabilities, some of which you highlight below. I thus take issue
with your statement 'Ideally in a big system like this we only want to
validate a
Spot on. This is exactly the point I was trying to make
David
On 24/11/2015 11:20, Dolph Mathews wrote:
> Scenarios I've been personally involved with where the
> "distrustful" model either did help or would have helped:
>
> - Employee is reprimanded by management for not positively reviewing &
On 23/11/2015 21:59, Clint Byrum wrote:
> Excerpts from David Chadwick's message of 2015-11-23 13:20:56 -0800:
>> Since the ultimate arbiter is the PTL, then it would be wrong to allow
>> members of the same organisation as the PTL to perform all three code
>> functions without the input of
Very sensible policy, Brad. Congrats to IBM for it
On 23/11/2015 21:38, Brad Topol wrote:
> Hi Morgan,
>
> So lots of good points below. However I am pulled in two directions on
> this topic.
>
> For small projects (e.g. pycadf, heat-translator) there are so few cores
> and the project is small
Since the ultimate arbiter is the PTL, then it would be wrong to allow
members of the same organisation as the PTL to perform all three code
functions without the input of anyone from any other organisation. This
places too much power in the hands of one organisation to the detriment
of the
gt; Thanks,
> Lin
>
>
>
> On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick <d.w.chadw...@kent.ac.uk
> <mailto:d.w.chadw...@kent.ac.uk>> wrote:
>
>
>
> On 07/10/2015 18:29, Adam Young wrote:
> > On 10/07/2015 11:51 AM, Adam Yo
this, so the patch is available for
> adoption. That way somebody else may be able to pick this up and work on
> it in the future, but Anton could get credit for the work he has done.
>
> Doug Fish
>
>
>
> - Original message -
> From: David Chadwi
> look at and potentially adopt.
>
>
>
> On 10/07/2015 11:37 AM, David Chadwick wrote:
>> Hi Douglas
>>
>> we are happy for you (or someone else) to submit the code in 3 names:
>> theirs, mine and Anton's. Then this third person can do all the work
>> necessary to g
made publicly available after the exam board next month.
Until then I will give out personal copies for private study.
regards
David
>
> This does not look like a radical stretch. It would be a decent
> opportunity for anyone looking to get involved with OpenStack to step
> into some
Dear All
One of my students, Anton Brida, has developed an Attribute Mapping GUI
for Horizon as part of his MSc project. Attribute mappings are an
essential, though complex, part of federated Keystone. Currently they
can only be created as JSON objects in the config file. The Horizon code
allows
On 11/09/2015 14:32, Rich Megginson wrote:
> On 09/11/2015 04:17 AM, David Chadwick wrote:
>> Whichever approach is adopted you need to consider the future and the
>> longer term objective of moving to fully hierarchical names. I believe
>> the current Keystone approach i
Whichever approach is adopted you need to consider the future and the
longer term objective of moving to fully hierarchical names. I believe
the current Keystone approach is only an interim one, as it only
supports partial hierarchies. Fully hierarchical names has been
discussed in the Keystone
Hi Morgan
I think you have been an excellent PTL, and I wish you all the best in
your future roles with OpenStack
regards
David
On 10/09/2015 22:40, Morgan Fainberg wrote:
> As I outlined (briefly) in my recent announcement of changes (
>
Hi Henry
in principle I think it is a good idea to have a user friendly name
attribute for every entity. The name should be unique amongst the same
set of entities (though not between entities since context should imply
what entity you are referring to), otherwise the name would have to be
Hi Jamie
see
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf
regards
David
On 13/08/2015 02:06, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Thursday, 13 August
I would also like a spec proposal freeze exception, but not if this
leads to a rushed design and a poor implementation that will need to be
fixed again during the next cycle. Its far better to get the right
design now, even if it means missing the liberty release, than to
implement a suboptimal
On 13/08/2015 02:22, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015
7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Hi Jamie
I have
the values in the horizon settings (idp+protocol)
But, it's already in keystone.
Thanks,
Steve Martinelli
OpenStack Keystone Core
Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM,
David Chadwick d.w.chadw...@kent.ac.uk wrote:
From: Dolph Mathews dolph.math
Hi Lance
On 12/08/2015 18:55, Lance Bragstad wrote:
On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 11/08/2015 01:46, Jamie Lennox wrote:
- Original Message -
From: Jamie Lennox
] [Keystone] [Horizon]
Federated Login
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015
12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
On 10/08/2015 01:53, Jamie
general for all
sorts of lists of entities?
regards
David
On 11/08/2015 10:55, Jesse Pretorius wrote:
On 6 August 2015 at 10:02, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
this is a value judgement that admins take. I think we should allow
On 10/08/2015 01:53, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Hi Jamie
nice
Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5,
2015 at 5:39 AM,
David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
wrote:
From: Dolph Mathews dolph.math...@gmail.com
On 07/08/2015 00:11, Dolph Mathews wrote:
As a federated end user in a public cloud, I'd be happy to have a
custom URL / bookmark for my IdP / domain (like
http://customer-x.cloud.example.com/ or
http://cloud.example.com/customer-x) that I need to know to kickoff
the
On 05/08/2015 18:36, Dolph Mathews wrote:
On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
On 04/08/2015 18:59, Steve Martinelli wrote:
Right, but that API is/should be protected. If we want to list IdPs
Horizon all the time.
Thanks,
Steve Martinelli
OpenStack Keystone Core
Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick
d.w.chadwicDolph Mathews ---2015/08/05 01:38
+protocol) But, it's already in keystone.
Thanks,
Steve Martinelli OpenStack Keystone Core
Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at
5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
From: Dolph Mathews dolph.math...@gmail.com To: OpenStack
for getting a
list of Identity Providers from Keystone
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers
Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015
06:01:48 AM: From: David Chadwick
for getting a list of Identity Providers from Keystone
_http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_
Doug Fish
David Chadwick _d.w.chadw...@kent.ac.uk_
mailto:d.w.chadw...@kent.ac.uk wrote on 08/01
://docs.openstack.org/developer/keystone/extensions/websso.html
[3] https://review.openstack.org/#/c/199339/
https://review.openstack.org/#/c/199339/
On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
Hi Everyone
I have a student
Hi All
Ioram has built a complete set of wireframe policy GUI screens for
comment. He has uploaded them to InVision
https://openstack.invisionapp.com/share/HQ3QN2123#/screens
Please comment on these in InVision
regards
David
On 03/08/2015 21:39, Lin Hua Cheng wrote:
Hi Timur,
Thanks for
?
No, Horizon uses the Keystone API
regards
David
Doug Fish
David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM:
From: David Chadwick d.w.chadw...@kent.ac.uk
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: 08/01/2015 06:05 AM
Subject
:
Hi David,
On 29.07.2015 18:59, David Chadwick wrote:
this is very helpful thanks, and it answers our question.
So to summarise, you can map a federated user into multiple
groups, or
into an existing local user/domain, but not into both, since the
latter
Hi Everyone
I have a student building a GUI for federated login with Horizon. The
interface supports both a drop down list of configured IDPs, and also
Type Ahead for massive federations with hundreds of IdPs. Screenshots
are visible in InVision here
https://invis.io/HQ3QN2123
All comments on
model for the right task. Using the wrong model will lead to
either over complication (DoA when subcontracting is sufficient) or
security vulnerability (subcontracting when DoA is needed)
regards
David
On 08/06/2015 15:10, Adam Young wrote:
On 06/06/2015 06:00 AM, David Chadwick wrote:
In order
that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute
On 06/05/2015 10:39 AM, Dolph Mathews wrote:
On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
I did suggest another solution to Adam whilst we were in Vancouver, and
this mirrors what happens
Hi Jamie
I think if we are going for hierarchical names we should do it properly
in one go ie. have a recursive scheme that allows infinite nesting of
name components, and then it will solve all current and future problems.
Having a half baked scheme which only allows one level of nesting, or
I did suggest another solution to Adam whilst we were in Vancouver, and
this mirrors what happens in the real world today when I order something
from a supplier and a whole supply chain is involved in creating the end
product that I ordered. This is not too dissimilar to a user requesting
a new
[mailto:ayo...@redhat.com]
Sent: Wednesday, June 3, 2015 4:39 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic
Policy
On 06/03/2015 02:55 PM, Sean Dague wrote:
On 06/03/2015 02:44 PM, David Chadwick wrote:
In the design
the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote
On 03/06/2015 19:55, Sean Dague wrote:
On 06/03/2015 02:44 PM, David Chadwick wrote:
In the design that we have been building for a policy administration
database, we dont require a single policy in order to unify common
concepts such as hierarchical attributes and roles between
delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
In the design that we have been building for a policy administration
database, we dont require a single policy in order to unify common
concepts such as hierarchical attributes and roles between the different
policies of Openstack services. This is because policies and hierarchies
are held
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a domain, we
should always reference the namespace as we do today. Basically, if we
ask for a project name we need to also provide it's namespace (your
option #1). This
it, there is no limitation on the number of
roles that can be defined in OpenStack.
regards
David
On 08/05/2015 15:52, Tim Hinrichs wrote:
Hi David,
See below.
On 5/7/15, 1:01 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi Tim
On 06/05/2015 21:53, Tim Hinrichs wrote:
I wondered if we could
Hi Tim
On 06/05/2015 21:53, Tim Hinrichs wrote:
I wondered if we could properly protect the API call for adding a new
Role using the current mechanism. So I came up with a simple example.
Suppose we want to write policy about the API call: addRole(user,
role-name). If we’re hosting both
. With this mechanism we should be able to create
a rule for multiple IdPs as well.
Guang
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, March 18, 2015 2:41
AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[Keystone][FFE] - IdP ID
In my opinion you have got into this situation because your federation
trust model is essentially misguided. As I have been arguing since the
inception of federated Keystone, you should have rules for trusted IdPs
(already done), trusted attributes (not done), and then one set of
mapping rules
Encryption per se does not decrease token size, the best it can do is
keep the token size the same size. So using Fernet tokens will not on
its own alter the token size. Reducing the size must come from putting
less information in the token. If the token recipient has to always go
back to Keystone
Hi Adam
prior art is the publish-subscribe mechanism. I dont know if Keystone
already has this implemented or not, or if Python implementation exists
or not, without doing some research
regards
David
On 16/03/2015 18:08, Sumit Naiksatam wrote:
On Mon, Mar 16, 2015 at 8:10 AM, Adam Young
screen, and
this summer I am hoping to have another student integrate this into the
current release, as well as make some enhancements to it (like
type-ahead searching for IdPs)
regards
David
On 23/02/2015 15:54, Adam Young wrote:
On 02/18/2015 12:02 PM, David Chadwick wrote:
I think this GUI
I think this GUI is not intuitive to users and therefore should not be
encouraged or supported.
If you ask a user what does authenticate via a Discovery Service mean?
I think you will get some very strange answers. The same goes for
Authenticate using Default Protocol. Users will have no idea
it easy for users to start doing real work.
Regards,
Brad
On 1/19/15, 10:03 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi Enrique
You are right in that we have been addressing different problems. There
are three aspects to managing users: registration, assigning
,
Enrique Garcia Navalon
On 16 January 2015 at 15:12, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
The VO code exists already, as does a public demo (see my original email
for details). I gave demos to the Keystone core in Paris last November.
How
solution.
Cheers,
-Adrian
On 15/01/15 21:20, David Chadwick wrote:
Hi Adrian
Morgan is right in saying that an external IdP would solve many of your
user management problems, but then of course, you will be using
federated keystone which you seem reluctant to do :-) However, if you
Hi Adrian
You might be glad to know that we have already produced a blueprint and
implementation for this, based on federated keystone and Horizon. You
can read the specs here
https://blueprints.launchpad.net/keystone/+spec/vo-management
and see a demo here
http://icehouse.sec.cs.kent.ac.uk/
implementers accept
that the current design is poor and needs re-engineering, then I will be
happy to propose a new design
regards
David
Marco
On Fri, Jan 02, 2015 at 09:51:55PM +, David Chadwick wrote:
Hi Marco
I think the current design is wrong because it is mixing up
.
This is not a huge change to make, in fact it should be a rather simple
re-engineering task.
regards
David
On 24/12/2014 17:50, Marco Fargetta wrote:
On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote:
If I understand the bug fix correctly, it is firmly tying the URL
On 23/12/2014 21:56, Morgan Fainberg wrote:
On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
mailto:dolph.math...@gmail.com wrote:
On Tue, Dec 23, 2014 at 1:33 PM, David
Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
Hi Adam
On 23/12
HI John
On 24/12/2014 14:15, John Dennis wrote:
Can't this be solved with a couple of environment variables? The two
keys pieces of information needed are:
1) who authenticated the subject?
AUTH_AUTHORITY or similar would stop wrong configuration of Apache if it
was set by the protocol
for
different URLs.
The second step, still in progress, is to include an ID in the IdP
configuration. My patch is under review here:
https://review.openstack.org/#/c/142743/
Let me know if it is enough to solve the issue in your case.
Marco
On 24 Dec 2014, at 10:08, David Chadwick d.w.chadw
Hi guys
we now have the ABFAB federation protocol working with Keystone, using a
modified mod_auth_kerb plugin for Apache (available from the project
Moonshot web site). However, we did not change Keystone configuration
from its original SAML federation configuration, when it was talking to
SAML
Hi Adam
On 23/12/2014 17:34, Adam Young wrote:
On 12/23/2014 11:34 AM, David Chadwick wrote:
Hi guys
we now have the ABFAB federation protocol working with Keystone, using a
modified mod_auth_kerb plugin for Apache (available from the project
Moonshot web site). However, we did not change
I tend to agree with Morgan. There are resources and there are users.
And there is something in the middle that says which users can access
which resources. It might be an ACL, a RBAC role, or a set of ABAC
attributes, or something else (such as a MAC policy). So to my mind this
middle bit, whilst
for the administrator to OK at a later time.
Users who try to hack in are blacklisted if they present a wrong secret
for 3 times.
Would this solve your problem?
regards
David
On 04/11/2014 15:30, John Dennis wrote:
On 11/04/2014 02:46 AM, David Chadwick wrote:
Hi John
Good morning David. I hope you're
I agree with Morgan. We designed the current mapping functionality to
cover all the use cases we were aware of, but if there are more, then we
would love to hear about them and make the fixes that are necessary.
Attribute mapping is a critical component of federation, and it should
be fit for
Hi John
Its seems like your objective is somewhat different to what was intended
with the current mapping rules. You seem to want a general purpose
mapping engine that can map from any set of attribute values into any
other set of values, whereas the primary objective of the current
mapping rules
Dave
when federation is used, the user's group is stored in a mapping rule.
So we do have a mechanism for storing group memberships without using
LDAP or creating an entry for the user in the SQL backend. (The only
time this is kinda not true is if we have a specific rule for each
federated user,
On 14/10/2014 01:25, Nathan Kinder wrote:
On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
Description of the problem: Without attempting an action on an
endpoint with a current scoped token, it is impossible to know what
actions are available to a user.
This is not unusual in the
Hi Doug
thanks. We will test this next week
regards
David
On 19/09/2014 18:43, Doug Hellmann wrote:
On Sep 19, 2014, at 6:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep 18, 2014, at 12:36 PM, David Chadwick
d.w.chadw...@kent.ac.uk wrote:
Our recent work on federation suggests we
#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API
calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon
Our recent work on federation suggests we need an improvement to the way
the policy engine works. My understanding is that most functions are
protected by the policy engine, but some are not. The latter functions
are publicly accessible. But there is no way in the policy engine to
specify public
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep 18, 2014, at 12:36 PM, David Chadwick
d.w.chadw...@kent.ac.uk wrote:
Our recent work on federation suggests we need an improvement to
the way the policy engine works. My understanding is that most
functions are protected by the policy
Hi Adam
Kristy has already added support to Horizon for federated login to
Keystone. She will send you details of how she did this.
One issue that arose was this:
in order to give the user the list of IDPs/protocols that are trusted,
the call to Keystone needs to be authenticated. But the user
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world but on the
other hand most cloud
this would work as well, but wouldn't it require two different API calls?
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making
/2014 15:14, Tim Bell wrote:
Has Kristy's patch made it into Juno ?
Tim
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@lists.openstack.org; Kristy Siu
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS
Tim
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@lists.openstack.org; Kristy Siu
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi Adam
Kristy has already added support to Horizon
) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote
Hi Everyone
at the Atlanta meeting the following slides were presented during the
federation session
http://www.slideshare.net/davidwchadwick/keystone-apach-authn
It was acknowledged that the current design is sub-optimal, but was a
best first efforts to get something working in time for the
In preparation for and input to today's design summit session on
Authorisation at 11.50am, I thought it might be beneficial to remind
folks of the proposed design that was circulated by me at the end of the
long discussion on the format of a scoped role, that was held at the end
of last year on
How about the following which clearly separates naming and scoping
constraints
{
role: {
id: 76e72a,
domain_id = --id--,(optional, if present, role is named by
specific domain)
project_id = --id--,(optional, if present, role is named
by project)
service_id =
or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.
Thoughts?
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December
Ack
On 09/12/2013 15:54, Tiwari, Arvind wrote:
Thanks David,
Let me update the etherpad with this proposal.
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Friday, December 06, 2013 2:44 AM
To: Tiwari, Arvind; Adam Young; OpenStack
On 09/12/2013 19:37, Adam Young wrote:
On 12/06/2013 04:44 AM, David Chadwick wrote:
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed
to be unique, is set by the role creator, can be any string in any
---
}
domain_id = --id--, (optional)
project_id = --id-- (optional)
}
}
Fields name, scope.id, domain_id and project_id makes the composite key.
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, December 09, 2013 1:28 PM
To: David Chadwick
Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 4:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone
a model to accommodate more
specialized cases. You enhance the model to take the new functionality
into account, and preferably in a backwards compatible way.
regards
David
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday
, November 26, 2013 4:08 PM
To: David Chadwick; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
Thanks for your time and valuable comments. I have replied to your
comments and try to explain why I am advocating to this BP
Thanks for your time,
Arvind
-Original Message-
From: Tiwari, Arvind
Sent: Monday, December 02, 2013 4:22 PM
To: Adam Young; OpenStack Development Mailing List (not for usage questions);
David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
means admin for service x from the default domain
etc.
will that work?
regards
David
On 04/12/2013 15:04, Adam Young wrote:
On 12/04/2013 04:08 AM, David Chadwick wrote:
I am happy with this as far as it goes. I would like to see it being
made more general, where domains, services and projects
.
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
for usage questions); Adam Young Subject: Re: [openstack-dev]
[keystone] Service scoped
...@gmail.com; David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below etherpad with
proposal for nested role definition
Updated. I made my changes
.
Let me know your thoughts, please feel free to update below etherpad
https://etherpad.openstack.org/p/service-scoped-role-definition
Thanks again,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, November 25, 2013 12:12 PM
Hi Arvind
I have just added some comments to your blueprint page
regards
David
On 19/11/2013 00:01, Tiwari, Arvind wrote:
Hi,
Based on our discussion in design summit , I have redone the service_id
binding with roles BP
of the true mapper table, who's sole job was to map
IDP groups into something keystone understands (usually a keystone group, I
would suggest)
I think that's we decided..or is the memory fading already
Henry
On 13 Nov 2013, at 17:00, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi
value.
On Oct 29, 2013, at 8:35 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Whilst on this topic, perhaps we should also expand it to discuss support for
external authz as well. I know that Adam at Red Hat is
working on adding additional authz attributes as env variables so
Whilst on this topic, perhaps we should also expand it to discuss
support for external authz as well. I know that Adam at Red Hat is
working on adding additional authz attributes as env variables so that
these can be used for authorising the user in keystone. It should be the
same module in
1 - 100 of 121 matches
Mail list logo
