Open Stack

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 <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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>