On 09/19/2014 01:43 PM, Doug Hellmann wrote:
On Sep 19, 2014, at 6:56 AM, David Chadwick <d.w.chadw...@kent.ac.uk> wrote:


On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick <d.w.chadw...@kent.ac.uk>
wrote:


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

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


_______________________________________________
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

_______________________________________________
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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to