[openstack-dev] [Keystone] [Horizon] Federated Login
David Chadwick
d.w.chadwick at kent.ac.uk
Tue Aug 11 12:31:55 UTC 2015
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 <d.w.chadwick at kent.ac.uk
> <mailto:d.w.chadwick at kent.ac.uk>> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list