On Sep 21, 2014, at 9:59 PM, Adam Young <[email protected]> wrote: > On 09/19/2014 01:43 PM, Doug Hellmann wrote: >> On Sep 19, 2014, at 6:56 AM, David Chadwick <[email protected]> wrote: >> >>> >>> On 18/09/2014 22:14, Doug Hellmann wrote: >>>> On Sep 18, 2014, at 4:34 PM, David Chadwick <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On 18/09/2014 21:04, Doug Hellmann wrote: >>>>>> On Sep 18, 2014, at 12:36 PM, David Chadwick >>>>>> <[email protected]> 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 [email protected] >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>> _______________________________________________ OpenStack-dev mailing >>>>>> list [email protected] >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>> >>> _______________________________________________ >>>>> OpenStack-dev mailing list [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ OpenStack-dev mailing >>>> list [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
