Re: [openstack-dev] [keystone][security] Service User Permissions

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 token

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

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 &

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

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 anyon

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

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 overall

Re: [openstack-dev] [horizon][keystone]

t; > Thanks, > Lin > > > > On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick <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 Young wrote: > >> Send me wha

Re: [openstack-dev] [horizon][keystone]

n be 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

Re: [openstack-dev] [horizon][keystone]

ok 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

Re: [openstack-dev] [horizon][keystone]

n't planning further work on 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

[openstack-dev] [horizon][keystone]

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 t

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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

Re: [openstack-dev] [keystone] PTL non-candidacy

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 ( > https://www.morganfainberg.com/blog/2015/09/09/openstac

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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 gro

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

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 combine

Re: [openstack-dev] [keystone] Liberty SPFE Request - IDP Specific WebSSO

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 des

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

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" To: >> openstack-dev@lists.openstack.org Sent: Thurs

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

On 13/08/2015 02:22, Jamie Lennox wrote: > > > - Original Message - >> From: "David Chadwick" To: >> openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 >> 7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] >> Federat

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

Hi Lance On 12/08/2015 18:55, Lance Bragstad wrote: > > > On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick > mailto:d.w.chadw...@kent.ac.uk>> wrote: > > > > On 11/08/2015 01:46, Jamie Lennox wrote: > > > > > > - Ori

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

gt;> >> >> >> Actually, I like jamie's suggestion of just making horizon a bit smarter, and >> expecting the values in the horizon settings (idp+protocol) >> But, it's already in keystone. >> >> >> >> >> >> >> >&

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

penstack-dev] [Keystone] [Horizon] >> Federated Login >> >> >> >> - Original Message - >>> From: "David Chadwick" To: >>> openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 >>> 12:50:21 AM Subject:

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

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 <mailto:d.w.chadw...@kent.ac.uk>> wrote: > > > this is a value judgement that admins take. I think we should allow this >

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

On 10/08/2015 01:53, Jamie Lennox wrote: > > > - Original Message - >> From: "David Chadwick" To: >> openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 >> 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] >>

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

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 >

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

custom text file/url that is maintained by the deployer. > Honestly if you're adding and removing idps this > frequently i don't mind making the deployer maintain > some of this information out of scope of keystone. > > >

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

On 05/08/2015 18:36, Dolph Mathews wrote: > > On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick <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

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

f you're > consistently adding Identity Providers, then your ops team might not > be too happy reconfiguring Horizon all the time. > > > > > Thanks, > > Steve Martinelli > OpenStack Keystone Core > > Inac

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

y i don't mind making the deployer maintain some > of this information out of scope of keystone. It cant be outside the scope of Keystone, since the list of trusted IdPs should be in Keystone regards David > > > Jamie > >> >> >> >> >>

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

penstack.invisionapp.com/d/main#/projects/2784587 > [2] http://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 <

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

t; Horizon and > Keystone so they both recognize the same list of idps? > > > There is an API call 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

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

e made a minor comment on >> it in InVision. I'm curious if this is an implementable idea - does >> keystone support large numbers of 3rd party idps? is there an API >> to retreive the list of idps or does this require carefully >> coordinated configuration betwe

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

ey both recognize the same list of idps? No, Horizon uses the Keystone API regards David > > Doug Fish > > > David Chadwick wrote on 08/01/2015 06:01:48 AM: > >> From: David Chadwick >> To: OpenStack Development Mailing List > >> Date: 08/01/2015 0

Re: [openstack-dev] [Keystone] [Horizon] UI for Keystone dynamic policies editing

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 fo

[openstack-dev] [Keystone] [Horizon] Federated Login

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 th

[openstack-dev] [Keystone] Attribute Mapping

: > 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/

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

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: >>

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

gt; don;t break exisiting deployments. >>> >>> Moving forward, we should support DNS notation, but it has to be an >>> opt in >>> >>>> >>>> The alternative is to explicitly list the delimiter in the project ( >>>> e.g. {&

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

e 05, 2015 4:11 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] [Glance][Keystone] Glance and trusts > > > > On 06/05/2015 10:39 AM, Dolph Mathews wrote: > > > > On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick > mailto:d.w.

Re: [openstack-dev] [Keystone] Domain and Project naming

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 requ

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

: {"delim": ".", "domain.project.project2"}} ). The > additional need to look up 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. > > --Morg

Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

-Original Message- > From: Adam Young [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

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

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 VM.

Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

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

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

ter. There would be no global hierarchy 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 &

Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

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 separate

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

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). Thi

Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc. - Role Assignment

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" wrote: > >> Hi Tim >> >> On 06/05/2015 21:53,

Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc. - Role Assignment

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 bo

Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation

ty-Provider", "any_one_of": > [ "https://acme.com/v3/OS-FEDERATION/saml2/idp"; ] } ] } ] } } > > Shibboleth do convey the "Shib-Identity-Provider" attribute in the > request environment. With this mechanism we should be able to create > a rule

Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation

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 that

Re: [openstack-dev] [keystone][congress][group-policy] Fetching policy from a remote source

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 wro

Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size

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

Re: [openstack-dev] [horizon][keystone]

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

Re: [openstack-dev] [horizon][keystone]

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

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

So we enable self registration and also set a few extra things up to make > it easy for users to start doing real work. > > Regards, > Brad > > > On 1/19/15, 10:03 AM, "David Chadwick" wrote: > >> Hi Enrique >> >> You are right in that we ha

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

osystem and how > would you do things differently. > > David, is this approach somewhat redundant with the federated Keystone > code you are working on? I feel like they address different use cases > but I might be looking at it the wrong way. > > ​regards, > Enrique ​Garcia

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

>> >> We need a solution in the next few months (ideally sooner), but while >> building a quick hack of a service along Keystone could likely be done >> quickly > , that wouldn't be a good long term solution. > >> >> Cheers, >> -Adrian >> &g

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

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 have an IdP under your full control then you can allow users to self register and

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

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/ (H

Re: [openstack-dev] [Keystone] Bug in federation

Not at the current time. There is little point in producing designs that no-one is willing to implement :-) Once the core 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 > > >

Re: [openstack-dev] [Keystone] Bug in federation

. 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 wrote: >> >> If I understand the bug fix correctly, it is firmly tying the

Re: [openstack-dev] [Keystone] Bug in federation

solve the issue in your case. > > Marco > >> On 24 Dec 2014, at 10:08, David Chadwick wrote: >> >> >> >> On 23/12/2014 21:56, Morgan Fainberg wrote: >>> >>>> On Dec 23, 2014, at 1:08 PM, Dolph Mathews >>> <ma

Re: [openstack-dev] [Keystone] Bug in federation

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 p

Re: [openstack-dev] [Keystone] Bug in federation

On 23/12/2014 21:56, Morgan Fainberg wrote: > >> On Dec 23, 2014, at 1:08 PM, Dolph Mathews > <mailto:dolph.math...@gmail.com>> wrote: >> >> >> On Tue, Dec 23, 2014 at 1:33 PM, David >> Chadwick mailto:d.w.chadw...@kent.ac.uk>> wrote: >>

Re: [openstack-dev] [Keystone] Bug in federation

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 >> Mo

[openstack-dev] [Keystone] Bug in federation

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 I

Re: [openstack-dev] [Keystone] Splitting up the assignment component

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

Re: [openstack-dev] [Keystone] Alternative federation mapping

ue 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 > > G

Re: [openstack-dev] [Keystone] Alternative federation mapping

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

Re: [openstack-dev] [Keystone] Alternative federation mapping

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 purpo

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

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,

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

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

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

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 wrote: > >> >> >> On 18/09/2014 22:14, Doug Hellmann wrote: >>> >>> On Sep 18

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

On 18/09/2014 22:14, Doug Hellmann wrote: > > On Sep 18, 2014, at 4:34 PM, David Chadwick > wrote: > >> >> >> On 18/09/2014 21:04, Doug Hellmann wrote: >>> >>> On Sep 18, 2014, at 12:36 PM, David Chadwick >>> wrote: >>>

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

On 18/09/2014 21:04, Doug Hellmann wrote: > > On Sep 18, 2014, at 12:36 PM, David Chadwick > 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

[openstack-dev] [Keystone][Oslo] Federation and Policy

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 ac

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

ult 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:

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

t; 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 th

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

partial VO documentation which will be stripped out until we can complete it later this month or next. regards David > > >> >> Tim >> >>> -Original Message- >>> From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] >>> Sent: 17 September 2

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 17/09/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

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

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 wrot

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

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

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

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 is

[openstack-dev] [keystone] Redesign of Keystone Federation

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 Ice

Re: [openstack-dev] [keystone] Service scoped role definition

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 thi

Re: [openstack-dev] [keystone] Service scoped role definition

not > stop anyone how don't want to included 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 > > >

Re: [openstack-dev] [keystone] Service scoped role definition

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)

Re: [openstack-dev] [keystone] Service scoped role definition

t;endpoint":"---endpoint---" > } > "domain_id" = "--id--", (optional) > "project_id" = "--id--" (optional) > } > } > Fields name, scope.id, domain_id and project_id makes the composite key. > > >

Re: [openstack-dev] [keystone] Service scoped role definition

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 creat

Re: [openstack-dev] [keystone] Service scoped role definition

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 >

Re: [openstack-dev] [keystone] Service scoped role definition

; Thanks, > Arvind > > -Original 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

Re: [openstack-dev] [keystone] Service scoped role definition

d use cases. That is counter-intuitive. You dont break 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-

Re: [openstack-dev] [keystone] Service scoped role definition

o their resources to the role > that they want to, except that they cannot override the scope field (ie. > grant permissions to resources which are out of the role's scope). > > 4. Remove any linkage of roles to tenants/projects on creation. This is > unnecessary baggage and only co

Re: [openstack-dev] [keystone] Service scoped role definition

oken as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq. > > David, I have updated > https://etherpad.openstack.org/p/service-scoped-role-definition line #118 > explaining the rationale behind the field. > I wd also appreciate your vision on > https://etherpad.openst

Re: [openstack-dev] [keystone] Service scoped role definition

ints.launchpad.net/keystone/+spec/service-scoped-tokens > BP. > > > 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

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 domain

Re: [openstack-dev] [keystone] Service scoped role definition

ervice-scoped-role-definition > > > 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 &g

Re: [openstack-dev] [keystone] Service scoped role definition

; Please take a look @ "Proposal (Ayoung) - Nested role definitions", I >> am sorry if I could not catch your idea. >> >> Feel free to update the etherpad. >> >> Regards, >> Arvind >> >> >> -Original Message- >> Fr

Re: [openstack-dev] [keystone] Service scoped role definition

penStack Development Mailing List (not for usage > questions) > Cc: Henry Nash; dolph.math...@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, >&g

Re: [openstack-dev] [keystone] Service scoped role definition

ting to this BP. > > 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

Re: [openstack-dev] [keystone] Service scoped role definition

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 >

  1   2   >