Open Stack

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

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
>