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.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. > > 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
