Open Stack

On 18/09/2014 21:04, Doug Hellmann wrote:
> 
> 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. 

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.

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 at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>