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