Open Stack

On Sep 18, 2014, at 12:36 PM, David Chadwick <d.w.chadwick at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev