Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-23 Thread David Chadwick
Hi Doug

thanks. We will test this next week

regards

David

On 19/09/2014 18:43, 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.
 
 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
 


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-22 Thread Doug Hellmann

On Sep 21, 2014, at 9:59 PM, Adam Young ayo...@redhat.com wrote:

 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.

Which “token” do you mean, something in the policy parser or the keystone 
token? Are you saying that the syntax I suggested isn’t valid and so can’t be 
parsed, or that some other part of the code is throwing an error before the 
policy module is ever being invoked?

 
 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
 
 

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-21 Thread Adam Young

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

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-19 Thread David Chadwick


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

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


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-19 Thread Doug Hellmann

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.

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


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-18 Thread Doug Hellmann

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


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-18 Thread David Chadwick


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.

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


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-18 Thread Doug Hellmann

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?

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


Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

2014-09-18 Thread Adam Young

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