Open Stack

On Sep 19, 2014, at 6:56 AM, David Chadwick <d.w.chadwick at 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.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?
> 
> You tell me. If there is, then problem solved. If not, then my request
> still stands

From looking at the code, it appears that something like True:”True” (or possibly True:True) would always pass, but I haven’t tested that.

Doug

> 
> regards
> 
> David
> 
>> 
>> 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
>> 
>> 
>> _______________________________________________ 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