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