On 09/18/2014 05:14 PM, 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.
More to the point: there is going to need to be a public list. It might
not have everything, but it will have a subset, and the user needs to
know what they are before they can authenticate. This absolutely needs
to be available before the user logs in.
Keystone is kindof a one off here, in that it is the only service that
does not run auth_token middleware (ATM for short) Every other service
that does can choose to split the token unpacking and the autentication
steps: there is a config option that says whether or not to treat a
missing token as an authentication error.
Keystone should make use of ATM, but in an short-circuited way as it
does not need to make remote calls to fetch things from Keystone. If
the token constriuction pipeline were pulled out of the current paste
API, this would be quite manageble.
I tinkered with pulling /auth and /token out from the /main /admin /v3
pipelines in the past. We need to stop the port 5000 and 35357 silliness
anyway, so this might just be the motivation we need.
One of the problems we have with moving things around is that we are not
RESTful: most of the clients know A-Priori where the resources are, and
moving them would break things. However, AUTH_URL is usually separate
from the endpoint returned in the service catalog. We could probably get
away with pulling that into its own suburl without changing the rest of
Keystone. Then it could be in its own paste pipeline without us having
to rewrite half of Keystone.
Good topic for the upcoming summit.
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 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
