Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
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 wrote: > >> >> >> On 18/09/2014 22:14, Doug Hellmann wrote: >>> >>> On Sep 18, 2014, at 4:34 PM, David Chadwick >>> wrote: >>> On 18/09/2014 21:04, Doug Hellmann wrote: > > On Sep 18, 2014, at 12:36 PM, David Chadwick > 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 >>> >>> >>> ___
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On Sep 21, 2014, at 9:59 PM, Adam Young wrote: > On 09/19/2014 01:43 PM, Doug Hellmann wrote: >> On Sep 19, 2014, at 6:56 AM, David Chadwick wrote: >> >>> >>> On 18/09/2014 22:14, Doug Hellmann wrote: On Sep 18, 2014, at 4:34 PM, David Chadwick wrote: > > On 18/09/2014 21:04, Doug Hellmann wrote: >> On Sep 18, 2014, at 12:36 PM, David Chadwick >> 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-
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On 09/19/2014 01:43 PM, Doug Hellmann wrote: On Sep 19, 2014, at 6:56 AM, David Chadwick wrote: On 18/09/2014 22:14, Doug Hellmann wrote: On Sep 18, 2014, at 4:34 PM, David Chadwick wrote: On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick 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/listi
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On Sep 19, 2014, at 6:56 AM, David Chadwick wrote: > > > On 18/09/2014 22:14, Doug Hellmann wrote: >> >> On Sep 18, 2014, at 4:34 PM, David Chadwick >> wrote: >> >>> >>> >>> On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick 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 >> > > ___
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On 18/09/2014 22:14, Doug Hellmann wrote: > > On Sep 18, 2014, at 4:34 PM, David Chadwick > wrote: > >> >> >> On 18/09/2014 21:04, Doug Hellmann wrote: >>> >>> On Sep 18, 2014, at 12:36 PM, David Chadwick >>> 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
On 09/18/2014 05:14 PM, Doug Hellmann wrote: On Sep 18, 2014, at 4:34 PM, David Chadwick wrote: On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick 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.
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On Sep 18, 2014, at 4:34 PM, David Chadwick wrote: > > > On 18/09/2014 21:04, Doug Hellmann wrote: >> >> On Sep 18, 2014, at 12:36 PM, David Chadwick >> 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
On 18/09/2014 21:04, Doug Hellmann wrote: > > On Sep 18, 2014, at 12:36 PM, David Chadwick > 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
On Sep 18, 2014, at 12:36 PM, David Chadwick 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
