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. Can you give a little more detail about why some providers would want to make it not public if we plan to make it public by default? If we think there’s a security issue, shouldn’t we just protect it? > > 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