Open Stack

On Sep 18, 2014, at 4:34 PM, David Chadwick <d.w.chadwick at 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.chadwick at 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 engine, but some are not. The
>>> latter functions are publicly accessible. But there is no way in
>>> the policy engine to specify public access to a function and there
>>> ought to be. This will allow an administrator to configure the
>>> policy for a function to range from very lax (publicly accessible)
>>> to very strict (admin only). A policy of "" means that any
>>> authenticated user can access the function. But there is no way in
>>> the policy to specify that an unauthenticated user (i.e. public)
>>> has access to a function.
>>> 
>>> We have already identified one function (get trusted IdPs 
>>> "identity:list_identity_providers") that needs to be publicly
>>> accessible in order for users to choose which IdP to use for
>>> federated login. However some organisations may not wish to make
>>> this API call publicly accessible, whilst others may wish to
>>> restrict it to Horizon only etc. This indicates that that the
>>> policy needs to be set by the administrator, and not by changes to
>>> the code (i.e. to either call the policy engine or not, or to have
>>> two different API calls).
>> 
>> I don’t know what list_identity_providers does. 
> 
> it lists the IDPs that Keystone trusts to authenticate users
> 
>> Can you give a little
>> more detail about why some providers would want to make it not public
> 
> I am not convinced that many cloud services will want to keep this list
> secret. Today if you do federated login, the public web page of the
> service provider typically lists the logos or names of its trusted IDPs
> (usually Facebook and Google). Also all academic federations publish
> their full lists of IdPs. But it has been suggested that some commercial
> cloud providers may not wish to publicise this list and instead require
> the end users to know which IDP they are going to use for federated
> login. In which case the list should not be public.
> 
> 
>> if we plan to make it public by default? If we think there’s a
>> security issue, shouldn’t we just protect it?
>> 
> 
> Its more a commercial in confidence issue (I dont want the world to know
> who I have agreements with) rather than a security issue, since the IDPs
> are typically already well known and already protect themselves against
> attacks from hackers on the Internet.

OK. The weak “someone might want to” requirement aside, and again showing my ignorance of implementation details, do we truly have to add a new feature to disable the policy check? Is there no way to have an “always allow” policy using the current syntax?

Doug

> 
> regards
> 
> David
> 
>>> 
>>> If we can invent some policy syntax that indicates public access,
>>> e.g. reserved keyword of public, then Keystone can always call the
>>> policy file for every function and there would be no need to
>>> differentiate between protected APIs and non-protected APIs as all
>>> would be protected to a greater or lesser extent according to the
>>> administrator's policy.
>>> 
>>> Comments please
>> 
>> It seems reasonable to have a way to mark a function as fully public,
>> if we expect to really have those kinds of functions.
>> 
>> Doug
>> 
>>> 
>>> regards
>>> 
>>> David
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ OpenStack-dev
>>> mailing list OpenStack-dev at lists.openstack.org 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________ OpenStack-dev mailing
>> list OpenStack-dev at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev