On Sep 21, 2014, at 9:59 PM, Adam Young <ayo...@redhat.com> wrote:

> On 09/19/2014 01:43 PM, Doug Hellmann wrote:
>> On Sep 19, 2014, at 6:56 AM, David Chadwick <d.w.chadw...@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.chadw...@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.chadw...@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.
> 
> Nope;  it errors out before it ever gets to the policy check, when it unpacks 
> the token.

Which “token” do you mean, something in the policy parser or the keystone 
token? Are you saying that the syntax I suggested isn’t valid and so can’t be 
parsed, or that some other part of the code is throwing an error before the 
policy module is ever being invoked?

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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to