This is essentially an access control issue. Ideally the existing access control mechanism should be sufficient to provide the functionality we want. If it is not, then it is better to change the underlying access control system rather than to add a patch to provide this specific bit of extra functionality for one use case.
The general functionality that is needed is to be able to access control a list of entities and make entries in the list accessible to different principals. We have come across this is two different scenarios and there are probably others that you can think of: i) the list of IdPs available for federated login ii) the list of conditions in a policy available to policy writers (some condition values might contain sensitive information) Swift already has this functionality for listing files in a directory. Can a project be started to make this functionality more 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 <[email protected] > <mailto:[email protected]>> wrote: > > > this is a value judgement that admins take. I think we should allow this > to be configurable, by either improving the policy engine to allow a > public access rule (coarse grained), or adding a public/private flag to > each configured IdP (fine grained) > > > Perhaps an idea which could evolve this and keep the settings in > keystone instead of splitting them between two projects: > > 1. Have the list of trusted dashboards be set per IDP - this would allow > that dashboard to list that IDP. > 2. If an IDP does not have any trusted dashboards listed, then assume > that it's public and fall back to the defaults set in keystone.conf > 3. Also enable the policies suggested by David above in order to cover > API security needs. Perhaps there needs to be some other sort of way of > doing fine-grained protection of information here? > > This would mean that Coke's dashboard would not be able to list Pepsi's > IDP at all. > > The trouble with allowing just a public flag on the IDP list is that > someone in Coke could still type other letters and see the list of other > providers, including Pepsi. Just a public/private flag is not good enough. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
