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