Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Jamie see http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf regards David On 13/08/2015 02:06, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 3:06:46 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 11/08/2015 01:46, Jamie Lennox wrote: - Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled by apache in the metadata xml files so we would have to add this information to keystone. Obviously this is doable just extra config setup that would require double handling of this URL. My idea is to use Horizon as the WAYF/Discovery service, approximately as follows 1. The user goes to Horizon to login locally or to discover which federated IdP to use 2. Horizon dynamically populates the list of IDPs by querying Keystone 3. The user chooses the IdP and Horizon redirects the user
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 13/08/2015 02:22, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie I have been thinking some more about your Coke and Pepsi use case example, and I think it is a somewhat spurious example, for the following reasons: 1. If Coke and Pepsi are members of the SAME federation, then they trust each other (by definition). Therefore they would not and could not object to being listed as alternative IdPs in this federation. 2. If Coke and Pepsi are in different federations because they dont trust each other, but they have the same service provider, then their service provider would be a member of both federations. In this case, the SP would provide different access points to the different federations, and neither Coke nor Pepsi would be aware of each other. regards David So yes, my point here is to number 2 and providing multitenancy in a way that you can't see who else is available, and in talking with some of the keystone people this is essentially what we've come to (and i think i mentioned earlier?) that you would need to provide a different access point to different companies not to the different companies, but to the different federations. This is fundamentally different. However, an SP within a federation may have a private contract with one organisation and provide a separate access point to it (which may have several IdPs associated with it). So I think that Keystone needs a way of indicating which groups of IdPs have similar relationships to the SP and need to be grouped together for display purposes. This brings me back to another related email I sent out. OpenStack needs a general way of applying access controls to list (tables) of entities. This would solve the current and other similar problems in a common way. to keep this information private. It has the side advantage for the public cloud folks of providing whitelabelling for horizon. The question then once you have multiple access points per customer (not user) is how to list IDPs that are associated with that customer. The example i had earlier was tagging so you could tag a horizon instance (probably doesn't need to be a whole instance, just a login page) with like a value like COKE and when you list IDPs from keystone you say list with tag=COKE to find out what should show in horizon. This would allow common idps like google to be reused. I think it is an authorisation issue, and tagging is no different to applying roles (except its less secure). If you have the right role, you get access to the list entry, otherwise you do not. This is secure. Tagging is not. It effectively allows anyone to claim any role they wish by saying I want tag Z. This is why i was saying that public/private may not be fine grained enough. Agreed. I is effectively a single role based system. It may also be not be a realistic concern. If we are talking a portal per customer does the cost of rebooting horizon to staticly add a new idp to the local_config matter? This is assumedly a rare operation. I think the answer has been for a while that idp listing is going to need to be configurable from horizon because we already have a case for list nothing, list everything, and use this static list, so if in future we find we need to add something more complex like tagging it's another option we can consider then. I dont think this is the correct approach. It is allowing the user (in this case Horizon) to apply his own access controls. regards David On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Jamie I have been thinking some more about your Coke and Pepsi use case example, and I think it is a somewhat spurious example, for the following reasons: 1. If Coke and Pepsi are members of the SAME federation, then they trust each other (by definition). Therefore they would not and could not object to being listed as alternative IdPs in this federation. 2. If Coke and Pepsi are in different federations because they dont trust each other, but they have the same service provider, then their service provider would be a member of both federations. In this case, the SP would provide different access points to the different federations, and neither Coke nor Pepsi would be aware of each other. regards David On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Lance On 12/08/2015 18:55, Lance Bragstad wrote: On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: On 11/08/2015 01:46, Jamie Lennox wrote: - Original Message - From: Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 3:06:46 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 11/08/2015 01:46, Jamie Lennox wrote: - Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled by apache in the metadata xml files so we would have to add this information to keystone. Obviously this is doable just extra config setup that would require double handling of this URL. My idea is to use Horizon as the WAYF/Discovery service, approximately as follows 1. The user goes to Horizon to login locally or to discover which federated IdP to use 2. Horizon dynamically populates the list of IDPs by querying Keystone 3. The user chooses the IdP and Horizon redirects the user to Apache/Keystone, telling it the IdP to use 4. Apache creates
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie I have been thinking some more about your Coke and Pepsi use case example, and I think it is a somewhat spurious example, for the following reasons: 1. If Coke and Pepsi are members of the SAME federation, then they trust each other (by definition). Therefore they would not and could not object to being listed as alternative IdPs in this federation. 2. If Coke and Pepsi are in different federations because they dont trust each other, but they have the same service provider, then their service provider would be a member of both federations. In this case, the SP would provide different access points to the different federations, and neither Coke nor Pepsi would be aware of each other. regards David So yes, my point here is to number 2 and providing multitenancy in a way that you can't see who else is available, and in talking with some of the keystone people this is essentially what we've come to (and i think i mentioned earlier?) that you would need to provide a different access point to different companies to keep this information private. It has the side advantage for the public cloud folks of providing whitelabelling for horizon. The question then once you have multiple access points per customer (not user) is how to list IDPs that are associated with that customer. The example i had earlier was tagging so you could tag a horizon instance (probably doesn't need to be a whole instance, just a login page) with like a value like COKE and when you list IDPs from keystone you say list with tag=COKE to find out what should show in horizon. This would allow common idps like google to be reused. This is why i was saying that public/private may not be fine grained enough. It may also be not be a realistic concern. If we are talking a portal per customer does the cost of rebooting horizon to staticly add a new idp to the local_config matter? This is assumedly a rare operation. I think the answer has been for a while that idp listing is going to need to be configurable from horizon because we already have a case for list nothing, list everything, and use this static list, so if in future we find we need to add something more complex like tagging it's another option we can consider then. On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 11/08/2015 01:46, Jamie Lennox wrote: - Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled by apache in the metadata xml files so we would have to add this information to keystone. Obviously this is doable just extra config setup that would require double handling of this URL. My idea is to use Horizon as the WAYF/Discovery service, approximately as follows 1. The user goes to Horizon to login locally or to discover which federated IdP to use 2. Horizon dynamically populates the list of IDPs by querying Keystone 3. The user chooses the IdP and Horizon redirects the user to Apache/Keystone, telling it the IdP to use 4. Apache creates the SAML assertion and sends it to the IDP. In order to use the standard SAML Discovery Protocol, then after step 1, Horizon would go to the Apache/Keystone entry point, and receive a Discovery Request. The message in step 3 would be the standard Discovery Response message. What do you think about this? David In a way
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 11/08/2015 01:46, Jamie Lennox wrote: - Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled by apache in the metadata xml files so we would have to add this information to keystone. Obviously this is doable just extra config setup that would require double handling of this URL. My idea is to use Horizon as the WAYF/Discovery service, approximately as follows 1. The user goes to Horizon to login locally or to discover which federated IdP to use 2. Horizon dynamically populates the list of IDPs by querying Keystone 3. The user chooses the IdP and Horizon redirects the user to Apache/Keystone, telling it the IdP to use 4. Apache creates the SAML assertion and sends it to the IDP. In order to use the standard SAML Discovery Protocol, then after step 1, Horizon would go to the Apache/Keystone entry point
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi On 05.08.2015 19:36, Dolph Mathews wrote: yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? Would Rackspace be happy to expose list of their customers to everybody? -- cheers Marek __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 6 August 2015 at 10:02, David Chadwick d.w.chadw...@kent.ac.uk wrote: this is a value judgement that admins take. I think we should allow this to be configurable, by either improving the policy engine to allow a public access rule (coarse grained), or adding a public/private flag to each configured IdP (fine grained) Perhaps an idea which could evolve this and keep the settings in keystone instead of splitting them between two projects: 1. Have the list of trusted dashboards be set per IDP - this would allow that dashboard to list that IDP. 2. If an IDP does not have any trusted dashboards listed, then assume that it's public and fall back to the defaults set in keystone.conf 3. Also enable the policies suggested by David above in order to cover API security needs. Perhaps there needs to be some other sort of way of doing fine-grained protection of information here? This would mean that Coke's dashboard would not be able to list Pepsi's IDP at all. The trouble with allowing just a public flag on the IDP list is that someone in Coke could still type other letters and see the list of other providers, including Pepsi. Just a public/private flag is not good enough. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
This is essentially an access control issue. Ideally the existing access control mechanism should be sufficient to provide the functionality we want. If it is not, then it is better to change the underlying access control system rather than to add a patch to provide this specific bit of extra functionality for one use case. The general functionality that is needed is to be able to access control a list of entities and make entries in the list accessible to different principals. We have come across this is two different scenarios and there are probably others that you can think of: i) the list of IdPs available for federated login ii) the list of conditions in a policy available to policy writers (some condition values might contain sensitive information) Swift already has this functionality for listing files in a directory. Can a project be started to make this functionality more general for all sorts of lists of entities? regards David On 11/08/2015 10:55, Jesse Pretorius wrote: On 6 August 2015 at 10:02, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: this is a value judgement that admins take. I think we should allow this to be configurable, by either improving the policy engine to allow a public access rule (coarse grained), or adding a public/private flag to each configured IdP (fine grained) Perhaps an idea which could evolve this and keep the settings in keystone instead of splitting them between two projects: 1. Have the list of trusted dashboards be set per IDP - this would allow that dashboard to list that IDP. 2. If an IDP does not have any trusted dashboards listed, then assume that it's public and fall back to the defaults set in keystone.conf 3. Also enable the policies suggested by David above in order to cover API security needs. Perhaps there needs to be some other sort of way of doing fine-grained protection of information here? This would mean that Coke's dashboard would not be able to list Pepsi's IDP at all. The trouble with allowing just a public flag on the IDP list is that someone in Coke could still type other letters and see the list of other providers, including Pepsi. Just a public/private flag is not good enough. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 10/08/2015 01:53, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Hi Jamie
nice presentation, thanks for sharing it. I have forwarded it to
my students working on federation aspects of Horizon.
About public federated cloud access, the way you envisage it, i.e.
that every user will have his own tailored (subdomain) URL to the
SP is not how it works in the real world today. SPs typically
provide one URL, which everyone from every IdP uses, so that no
matter which browser you are using, from wherever you are in the
world, you can access the SP (via your IdP). The only thing the
user needs to know, is the name of his IdP, in order to correctly
choose it.
So discovery of all available IdPs is needed. You are correct in
saying that Shib supports a separate discovery service (WAYF), but
Horizon can also play this role, by listing the IdPs for the user.
This is the mod that my student is making to Horizon, by adding
type ahead searching.
So my point at the moment is that unless there's something i'm
missing in the way shib/mellon discovery works is that horizon can't.
Because we forward to a common websso entry point there is no way (i
know) for the users selection in horizon to be forwarded to keystone.
You would still need a custom select your idp discovery page in
front of keystone. I'm not sure if this addition is part of your
students work, it just hasn't been mentioned yet.
About your proposed discovery mod, surely this seems to be going in
the wrong direction. A common entry point to Keystone for all IdPs,
as we have now with WebSSO, seems to be preferable to separate
entry points per IdP. Which high street shop has separate doors for
each user? Or have I misunderstood the purpose of your mod?
The purpose of the mod is purely to bypass the need to have a
shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
page is currently required to allow a user to select their idp
(presumably from the ones supported by keystone) and redirect to that
IDPs specific login page.
There are two functionalities that are required:
a) Horizon finding the redirection login URL of the IdP chosen by the user
b) Keystone finding which IdP was used for login.
The second is already done by Apache telling Keystone in the header field.
The first is part of the metadata of the IdP, and Keystone should make
this available to Horizon via an API call. Ideally when Horizon calls
Keystone for the list of trusted IdPs, then the user friendly name of
the IdP (to be displayed to the user) and the login page URL should be
returned. Then Horizon can present the user friendly list to the user,
get the login URL that matches this, then redirect the user to the IdP
telling the IdP the common callback URL of Keystone.
When the response comes back from that
login it returns to that websso page and we look at remote_ids to
determine which keystone idp is handling the response from that
site.
This seems the more secure way of determining the IdP to me, since
Apache determines the IdP then tells Keystone via the header field. If
you rely on the IdP to contact the right endpoint, then doesn't this
allow the IdP to return to a different URL and thereby trick Keystone
into thinking it was a different IdP?
regards
David
If we were to move that to
/v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/saml2/websso
then we can more easily support selection from horizon, or otherwise
do discovery without relying on shib/mellons discovery mechanism. A
selection from horizon would forward us to the idp specific websso on
keystone, which would forward to the idp's login page (without
needing discovery because we already know the idp) and the response
from login would go to the idp specific page negating the need for
dealing with remote_ids.
So i'm not looking for a seperate door so much as a way to indicate
that the user picked an IDP in horizon and i don't want to do
discovery again.
regards
David
On 07/08/2015 01:29, Jamie Lennox wrote:
*From: *Dolph Mathews dolph.math...@gmail.com
*To: *OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org *Sent: *Friday,
August 7, 2015 9:09:25 AM *Subject: *Re: [openstack-dev]
[Keystone] [Horizon] Federated Login
On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad
lbrags...@gmail.com mailto:lbrags...@gmail.com wrote:
On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
dolph.math...@gmail.com mailto:dolph.math...@gmail.com
wrote:
On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
jamielen...@redhat.com mailto:jamielen...@redhat.com wrote:
- Original Message -
From: David Lyle dkly
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. In a way this is exactly what my proposal was. A way for horizon to determine a unique websso login page for each idp, just my understanding is that this request must be bounced through keystone. When the response comes back from that login it returns to that websso page and we look at remote_ids to determine which keystone idp is handling the response from that site. This seems the more secure way of determining the IdP to me, since Apache determines the IdP then tells Keystone via the header field. If you rely on the IdP to contact the right endpoint, then doesn't this allow the IdP to return to a different URL and thereby trick Keystone into thinking it was a different IdP? To me the difference is that if we all return to a common /OS-FEDERATION/websso/saml2 endpoint then apache has to let all SAML responses through for all registered idps and then keystone must determine which is the real idp. By returning to an IDP specific websso route apache can assert that this response may only have come from the provider configured for that idp. This is really a secondary concern. I don't see there being much security difference, just that in this way you offload some additional responsibility for validating a SAML assertion to apache and we remove some (not all
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. So my point at the moment is that unless there's something i'm missing in the way shib/mellon discovery works is that horizon can't. Because we forward to a common websso entry point there is no way (i know) for the users selection in horizon to be forwarded to keystone. You would still need a custom select your idp discovery page in front of keystone. I'm not sure if this addition is part of your students work, it just hasn't been mentioned yet. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? The purpose of the mod is purely to bypass the need to have a shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently required to allow a user to select their idp (presumably from the ones supported by keystone) and redirect to that IDPs specific login page. There are two functionalities that are required: a) Horizon finding the redirection login URL of the IdP chosen by the user b) Keystone finding which IdP was used for login. The second is already done by Apache telling Keystone in the header field. The first is part of the metadata of the IdP, and Keystone should make this available to Horizon via an API call. Ideally when Horizon calls Keystone for the list of trusted IdPs, then the user friendly name of the IdP (to be displayed to the user) and the login page URL should be returned. Then Horizon can present the user friendly list to the user, get the login URL that matches this, then redirect the user to the IdP telling the IdP the common callback URL of Keystone. So my understanding was that this wasn't possible. Because we want to have keystone be the registered service provider and receive the returned SAML assertions the login redirect must be issued from keystone and not horizon. Is it possible to issue a login request from horizon that returns the response to keystone? This seems dodgy to me but may be possible if all the trust relationships are set up. Note also that currently this metadata including the login URL is not known by keystone. It's controlled by apache in the metadata xml files so we would have to add this information to keystone. Obviously this is doable just extra config setup that would require double handling of this URL. In a way this is exactly what my proposal was. A way for horizon to determine a unique websso login page for each idp, just my understanding is that this request must be bounced through keystone. When the response comes back from that login it returns to that websso page and we look at remote_ids to determine which keystone idp is handling the response from that site. This seems the more secure way of determining the IdP to me, since Apache determines the IdP then tells Keystone via the header field. If you rely on the IdP to contact the right endpoint, then doesn't this allow the IdP to return to a different
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Sunday, August 9, 2015 12:29:49 AM
Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Jamie
nice presentation, thanks for sharing it. I have forwarded it to my
students working on federation aspects of Horizon.
About public federated cloud access, the way you envisage it, i.e. that
every user will have his own tailored (subdomain) URL to the SP is not
how it works in the real world today. SPs typically provide one URL,
which everyone from every IdP uses, so that no matter which browser you
are using, from wherever you are in the world, you can access the SP
(via your IdP). The only thing the user needs to know, is the name of
his IdP, in order to correctly choose it.
So discovery of all available IdPs is needed. You are correct in saying
that Shib supports a separate discovery service (WAYF), but Horizon can
also play this role, by listing the IdPs for the user. This is the mod
that my student is making to Horizon, by adding type ahead searching.
So my point at the moment is that unless there's something i'm missing in the
way shib/mellon discovery works is that horizon can't. Because we forward to a
common websso entry point there is no way (i know) for the users selection in
horizon to be forwarded to keystone. You would still need a custom select your
idp discovery page in front of keystone. I'm not sure if this addition is part
of your students work, it just hasn't been mentioned yet.
About your proposed discovery mod, surely this seems to be going in the
wrong direction. A common entry point to Keystone for all IdPs, as we
have now with WebSSO, seems to be preferable to separate entry points
per IdP. Which high street shop has separate doors for each user? Or
have I misunderstood the purpose of your mod?
The purpose of the mod is purely to bypass the need to have a shib/mellon
discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently
required to allow a user to select their idp (presumably from the ones
supported by keystone) and redirect to that IDPs specific login page. When the
response comes back from that login it returns to that websso page and we look
at remote_ids to determine which keystone idp is handling the response from
that site.
If we were to move that to
/v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/saml2/websso then we
can more easily support selection from horizon, or otherwise do discovery
without relying on shib/mellons discovery mechanism. A selection from horizon
would forward us to the idp specific websso on keystone, which would forward to
the idp's login page (without needing discovery because we already know the
idp) and the response from login would go to the idp specific page negating the
need for dealing with remote_ids.
So i'm not looking for a seperate door so much as a way to indicate that the
user picked an IDP in horizon and i don't want to do discovery again.
regards
David
On 07/08/2015 01:29, Jamie Lennox wrote:
*From: *Dolph Mathews dolph.math...@gmail.com
*To: *OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
*Sent: *Friday, August 7, 2015 9:09:25 AM
*Subject: *Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com
mailto:lbrags...@gmail.com wrote:
On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote:
On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
jamielen...@redhat.com mailto:jamielen...@redhat.com wrote:
- Original Message -
From: David Lyle dkly...@gmail.com
mailto:dkly...@gmail.com
To: OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Sent: Thursday, August 6, 2015 5:52:40 AM
Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Forcing Horizon to duplicate Keystone settings just makes
everything much
harder to configure and much more fragile. Exposing
whitelisted, or all,
IdPs makes much more sense.
On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews
dolph.math...@gmail.com mailto:dolph.math...@gmail.com
wrote:
On Wed, Aug 5
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Jamie nice presentation, thanks for sharing it. I have forwarded it to my students working on federation aspects of Horizon. About public federated cloud access, the way you envisage it, i.e. that every user will have his own tailored (subdomain) URL to the SP is not how it works in the real world today. SPs typically provide one URL, which everyone from every IdP uses, so that no matter which browser you are using, from wherever you are in the world, you can access the SP (via your IdP). The only thing the user needs to know, is the name of his IdP, in order to correctly choose it. So discovery of all available IdPs is needed. You are correct in saying that Shib supports a separate discovery service (WAYF), but Horizon can also play this role, by listing the IdPs for the user. This is the mod that my student is making to Horizon, by adding type ahead searching. About your proposed discovery mod, surely this seems to be going in the wrong direction. A common entry point to Keystone for all IdPs, as we have now with WebSSO, seems to be preferable to separate entry points per IdP. Which high street shop has separate doors for each user? Or have I misunderstood the purpose of your mod? regards David On 07/08/2015 01:29, Jamie Lennox wrote: *From: *Dolph Mathews dolph.math...@gmail.com *To: *OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Sent: *Friday, August 7, 2015 9:09:25 AM *Subject: *Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com mailto:lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com mailto:dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com mailto:steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM http://COKE.COM domain and i can see for example that PEPSI.COM http://PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM http://COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM http://COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 07/08/2015 00:11, Dolph Mathews wrote: As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x) that I need to know to kickoff the correct federated handshake with my IdP using a single button press (Login). The benefit of the first example is that I can easily setup DNS to redirect cloud.customer-x.com http://cloud.customer-x.com to customer-x.cloud.example.com http://customer-x.cloud.example.com, where example.com http://example.com is my public cloud provider. The benefit of the second example is that it's completely trivial for the public cloud provider to implement. How do you expect this to work when the public service is listed in some public directory or search engine like google? How will any user from any organisation know how to contact this service, http://service.com? Should it be http://service.com/myOrg http://service.com/Organisation http://service.com/Org.com the potential values for the name of each IdP are endless. Users will never know what to use, remembering also that the URL is case sensitive. regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 08/06/2015 07:09 PM, Dolph Mathews wrote: On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com mailto:lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com mailto:dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com mailto:steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM http://COKE.COM domain and i can see for example that PEPSI.COM http://PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM http://COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM http://COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. The user would be required to know the id of the IdP in which they want to federate with, right? As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x) that I need to know to kickoff the correct federated handshake with my IdP using a single button press (Login). Are we going about this backwards? Wouldn't it make more sense to tell a new customer: you get https://coke.cloudprovider.net And have that hard coded to a UI. For larger organizations, I suspect it would make more sense that the UI should be owned by Coke, and run on a server managed by Coke, and talk to multiple OpenStack instances. The UI should not be Provider specific, but consumer specific. In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 6:25:29 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. This is the whole purpose of the mod we are currently making to Horizon. If you look at our screenshots on InVision, you will see the user has the choice to either list all (potentially hundreds of) IdPs, or start to type in the name of his organisation. With type ahead, we then filter the IdPs to match the characters the user enters. This is also shown in our screenshots. So using your coke/pepsi example above, the Coke user would type C and the list of IdPs would be immediately culled to only contain those with C in their name (and pepsi would be removed from the list). When he enters O then the list is further culled to only IdPs containing co in their name. Consequently with only minor effort from the user (both mental load and physical load) the user's IdP is very quickly revealed to him, allowing him to login. See https://openstack.invisionapp.com/d/#/console/4277424/92772663/preview So my point here was that in many situations you strictly don't want to allow people to see this entire list. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. Actually gmail (at least for me) works in a different way. It takes your email address and ASSUMES that your idp is the same as your domain name. So no list of IdPs is presented. Instead the IdP name is computed automatically from your email address. This approach wont work for everyone. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. @David - when you add a new IdP to the university network are you the list of IdPs is centrally (i.e. nationally) managed, and every UK university/federation member is sent a new list periodically. So we do not add new IdPs, we simply use the list that is provided to us. having to provide a new mapping each time? Since all federation members use the EduPerson schema, then one set of mapping rules are applicable to all IdPs. They dont need to be updated. So to conclude a) we dont need to do anything when the federation membership changes (except use the new list) b) we dont need to change mapping rules c) we dont need to tailor user interfaces We would like to move OpenStack in this direction, where there is minimal effort to managing federation membership. We believe our proposed change to Horizon is one step in the right direction. I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Not a good solution from a trust perspective since you dont know who the actual IdP is. You are told it is always the proxy IdP. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 08/06/2015 04:56 AM, David Chadwick wrote: On 05/08/2015 19:28, Thai Q Tran wrote: I agree with Lance. Quite honestly, the list of Idps does not belong in horizon's settings. Just throwing out some ideas, why not white-list the Idps you want public it in keystone's settings, and have an API call for that? that was the conclusion reached many months ago the last time this was discussed. regards David Posted a spec for review here. It needs a corresponding API change. https://review.openstack.org/#/c/209941/ - Original message - From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Date: Wed, Aug 5, 2015 11:19 AM On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com mailto:steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) This *might* lead to a more complicated user experience, unless we deduce the protocol for the IdP selected (but that would defeat the point?). Also, wouldn't we have to make changes to Horizon every time we add an IdP? This might be case by case, but if you're consistently adding Identity Providers, then your ops team might not be too happy reconfiguring Horizon all the time. Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwicDolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk wrote: * On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? * regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad _lbragstad@gmail.com_ mailto:lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:_drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. The user would be required to know the id of the IdP in which they want to federate with, right? As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x) that I need to know to kickoff the correct federated handshake with my IdP using a single button press (Login). In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. The user would be required to know the id of the IdP in which they want to federate with, right? As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x) that I need to know to kickoff the correct federated handshake with my IdP using a single button press (Login). The benefit of the first example is that I can easily setup DNS to redirect cloud.customer-x.com to customer-x.cloud.example.com, where example.com is my public cloud provider. The benefit of the second example is that it's completely trivial for the public cloud provider to implement. In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, August 7, 2015 9:09:25 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. The user would be required to know the id of the IdP in which they want to federate with, right? As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x ) that I need to know to kickoff the correct federated handshake with my IdP using a single button press (Login). I always envisioned the subdomain method. I would say no to listing IdPs, but it's not simply making the list private because you will still need to provide at least one IdP option manually in that horizon's local_settings and at which point you should just turn off listing because you know it's always going to get a 403. I'm not sure how this would be managed today because we have a single WebSSO entry point so you can't really specify the IdP you want from the login page, it's expected to have your own discovery page - hence the spec https://review.openstack.org/#/c/199339/ In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. I don't think so. I think privately you would list everything. I feel at this point I'm missing something obvious, so let me explain my understanding of the current flow. * From horizon you select federated provider, the key of this is a protocol name, eg saml. * On login you get redirected
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 05/08/2015 18:36, Dolph Mathews wrote: On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? this is a value judgement that admins take. I think we should allow this to be configurable, by either improving the policy engine to allow a public access rule (coarse grained), or adding a public/private flag to each configured IdP (fine grained) regards David regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com mailto:drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad lbrags...@gmail.com mailto:lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com mailto:drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:_ __openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: _openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 05/08/2015 19:28, Thai Q Tran wrote: I agree with Lance. Quite honestly, the list of Idps does not belong in horizon's settings. Just throwing out some ideas, why not white-list the Idps you want public it in keystone's settings, and have an API call for that? that was the conclusion reached many months ago the last time this was discussed. regards David - Original message - From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Date: Wed, Aug 5, 2015 11:19 AM On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com mailto:steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) This *might* lead to a more complicated user experience, unless we deduce the protocol for the IdP selected (but that would defeat the point?). Also, wouldn't we have to make changes to Horizon every time we add an IdP? This might be case by case, but if you're consistently adding Identity Providers, then your ops team might not be too happy reconfiguring Horizon all the time. Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwicDolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk wrote: * On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? * regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad _lbragstad@gmail.com_ mailto:lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:_drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. The user would be required to know the id of the IdP in which they want to federate with, right? In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. This is the whole purpose of the mod we are currently making to Horizon. If you look at our screenshots on InVision, you will see the user has the choice to either list all (potentially hundreds of) IdPs, or start to type in the name of his organisation. With type ahead, we then filter the IdPs to match the characters the user enters. This is also shown in our screenshots. So using your coke/pepsi example above, the Coke user would type C and the list of IdPs would be immediately culled to only contain those with C in their name (and pepsi would be removed from the list). When he enters O then the list is further culled to only IdPs containing co in their name. Consequently with only minor effort from the user (both mental load and physical load) the user's IdP is very quickly revealed to him, allowing him to login. See https://openstack.invisionapp.com/d/#/console/4277424/92772663/preview Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. Actually gmail (at least for me) works in a different way. It takes your email address and ASSUMES that your idp is the same as your domain name. So no list of IdPs is presented. Instead the IdP name is computed automatically from your email address. This approach wont work for everyone. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. @David - when you add a new IdP to the university network are you the list of IdPs is centrally (i.e. nationally) managed, and every UK university/federation member is sent a new list periodically. So we do not add new IdPs, we simply use the list that is provided to us. having to provide a new mapping each time? Since all federation members use the EduPerson schema, then one set of mapping rules are applicable to all IdPs. They dont need to be updated. So to conclude a) we dont need to do anything when the federation membership changes (except use the new list) b) we dont need to change mapping rules c) we dont need to tailor user interfaces We would like to move OpenStack in this direction, where there is minimal effort to managing federation membership. We believe our proposed change to Horizon is one step in the right direction. I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Not a good solution from a trust perspective since you dont know who the actual IdP is. You are told it is always the proxy IdP. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. It cant be outside the scope of Keystone, since the list of trusted IdPs should be in Keystone regards David Jamie Actually, I like jamie's suggestion
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. That all makes sense, and I was admittedly only thinking of the private cloud use case. So, I'd like to discuss the public and private use cases separately: In a public cloud, is there a real use case for revealing *any* IdPs publicly? If not, the entire list should be made private using policy.json, which we already support today. In a private cloud, is there a real use case for fine-grained public/private attributes per IdP? (The stated use case was for a public cloud.) It seems the default behavior should be that horizon fetches the entire list from keystone. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Jamie
On 05/08/2015 00:46, Jamie Lennox wrote:
- Original Message -
From: Steve Martinelli steve...@ca.ibm.com To: OpenStack
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org Sent: Wednesday, August 5, 2015
3:59:34 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Right, but that API is/should be protected. If we want to list IdPs
*before* authenticating a user, we either need: 1) a new API for
listing public IdPs or 2) a new policy that doesn't protect that
API.
Thanks,
Is there a real requirement here for this to be a dynamic listing
Yes. As the size of federations increase, then dynamic listing is the
only sensible approach otherwise you will be reconfiguring Horizon every
day. In the worldwide academic community (EduGain) we already have
hundreds of IdPs.
as
opposed to something that can be edited from the horizon
local_settings? There are obvious use cases for both situations where
you want this to be dynamic or you very carefully want to protect
which IdPs are available to log in with and from that perspective it
would be a very unusual API for keystone to have.
We discussed this many months back and two approaches were proposed then
a) alter the policy that currently controls the API that lists IdPs to
allow 'public access' to be a policy option. The current policy engine
does not support 'public access', but only 'anyone who has been
authenticated', and this is too restrictive for federated login where
the user has not yet been authenticated. In this way different sites can
configure their policy to give public access to IdPs or not.
b) edit the list of IdPs to say whether they are publicly accessible or
not, and create a new publicly accessible API that lists only the public
IdPs. Horizon can then be configured to call either the public list of
IdPs or all IdPs, since Horizon is an authenticated user.
I thought that option b) had been chosen as the preferred approach, but
I don't know whether it was implemented or not. If it has been, then I
don't see what extra functionality is needed
regards
David
My understanding of the current websso design where we always logged
in via /v3/OS-FEDERATION/auth/websso/{protocol} was so that you would
run a discovery page on that address that allowed you to customize
which IdPs you exposed outside of keystone. Personally i don't like
this which is what i wrote this spec[1] was for. However my intention
there would have been to manually specify in the local_settings what
IdPs were available and reuse the current horizon WebSSO drop down
box.
Jamie
[1] https://review.openstack.org/#/c/199339/
Steve Martinelli OpenStack Keystone Core
Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at
10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David,
From: Lance Bragstad lbrags...@gmail.com To: OpenStack
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM
Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com
wrote:
Hi David, This is a cool looking UI. I've made a minor comment on
it in InVision. I'm curious if this is an implementable idea - does
keystone support large numbers of 3rd party idps? is there an API
to retreive the list of idps or does this require carefully
coordinated configuration between Horizon and Keystone so they both
recognize the same list of idps? There is an API call for getting a
list of Identity Providers from Keystone
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers
Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015
06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM
Subject: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Everyone I have a student building a GUI for federated login
with Horizon. The interface supports both a drop down list of
configured IDPs, and also Type Ahead for massive federations
with hundreds of IdPs. Screenshots are visible in InVision here
https://invis.io/HQ3QN2123 All comments on the design are
appreciated. You can make them directly to the screens via
InVision Regards David
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions) Unsubscribe:
openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:_ __openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: _openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ __http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On 04/08/2015 17:51, Lin Hua Cheng wrote: Hi David, There was a similar effort in Kilo to design the flow in the login page for federated login[1]. WebSSO feature[2] was implemented in Kilo, it allows the user to perform federated login by selecting an IdP protocol. This have tested with kerberos and saml2. This is not a very user friendly thing to do. Users typically have no idea what a federation protocol is, and wont know which one to select. They will however know which organisation (IdP) they are associated with and can use for federated login. We have been following the best practice guide available here https://discovery.refeds.org/guide/ There is a proposal to extend that feature to show listing per Idp/Protocol instead [3], because just listing only by protocol is fairly limited . Our intention is to list by organisation/IdP only and not to mention the protocol to the user, since it is meaningless to him. Horizon can work the protocol out itself and use the correct one, without burdening the user with extra mental effort that will only confuse, frustrate and distress I think the Type Ahead can fit it nicely when we implement the support for WebSSO by IdP/Protocol. Agreed, type ahead was introduced after many years of simple listing, since once federation grew to any appreciable size, the listing became unusable. regards David thanks, Lin [1] https://openstack.invisionapp.com/d/main#/projects/2784587 [2] http://docs.openstack.org/developer/keystone/extensions/websso.html [3] https://review.openstack.org/#/c/199339/ https://review.openstack.org/#/c/199339/ On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _ http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:_ __openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe _ http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: _openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ __http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Some folks said that they'd prefer not to list all associated idps, which i can understand. Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) Thanks, Steve Martinelli OpenStack Keystone Core From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject:Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _ http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:_ __openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe _ http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: _openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ __ http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) This *might* lead to a more complicated user experience, unless we deduce the protocol for the IdP selected (but that would defeat the point?). Also, wouldn't we have to make changes to Horizon every time we add an IdP? This might be case by case, but if you're consistently adding Identity Providers, then your ops team might not be too happy reconfiguring Horizon all the time. Thanks, Steve Martinelli OpenStack Keystone Core [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwic]Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login -- On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick *d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish *drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad *lbrags...@gmail.com* lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:*drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _ *http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_* http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:*openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _*https://invis.io/HQ3QN2123_* https://invis.io/HQ3QN2123_ All comments
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
text/html; charset=UTF-8: Unrecognized __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwic]Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login -- On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick *d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish *drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad *lbrags...@gmail.com* lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:*drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _ *http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_* http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:*openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _*https://invis.io/HQ3QN2123_* https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwic]Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login -- On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick *d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish *drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad *lbrags...@gmail.com* lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto:*drf...@us.ibm.com* drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone _ *http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_* http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ Doug Fish David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick _d.w.chadw...@kent.ac.uk_ mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List _openstack-dev@lists.openstack.org_ mailto:*openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here _*https://invis.io/HQ3QN2123_* https://invis.io/HQ3QN2123_ All comments on the design are appreciated. You can make them directly to the screens via
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com wrote: Some folks said that they'd prefer not to list all associated idps, which i can understand. Why? So the case i heard and i think is fairly reasonable is providing corporate logins to a public cloud. Taking the canonical coke/pepsi example if i'm coke, i get asked to login to this public cloud i then have to scroll though all the providers to find the COKE.COM domain and i can see for example that PEPSI.COM is also providing logins to this cloud. Ignoring the corporate privacy implications this list has the potential to get long. Think about for example how you can do a corporate login to gmail, you certainly don't pick from a list of auth providers for gmail - there would be thousands. My understanding of the usage then would be that coke would have been provided a (possibly branded) dedicated horizon that backed onto a public cloud and that i could then from horizon say that it's only allowed access to the COKE.COM domain (because the UX for inputting a domain at login is not great so per customer dashboards i think make sense) and that for this instance of horizon i want to show the 3 or 4 login providers that COKE.COM is going to allow. Anyway you want to list or whitelist that in keystone is going to involve some form of IdP tagging system where we have to say which set of idps we want in this case and i don't think we should. @David - when you add a new IdP to the university network are you having to provide a new mapping each time? I know the CERN answer to this with websso was to essentially group many IdPs behind the same keystone idp because they will all produce the same assertion values and consume the same mapping. Maybe the answer here is to provide the option in django_openstack_auth, a plugin (again) of fetch from keystone, fixed list in settings or let it point at a custom text file/url that is maintained by the deployer. Honestly if you're adding and removing idps this frequently i don't mind making the deployer maintain some of this information out of scope of keystone. Jamie Actually, I like jamie's suggestion of just making horizon a bit smarter, and expecting the values in the horizon settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/05 01:38 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Hi Steve yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? regards David Thanks, Steve Martinelli OpenStack Keystone Core Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_ mailto: drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
- Original Message -
From: Steve Martinelli steve...@ca.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Wednesday, August 5, 2015 3:59:34 AM
Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Right, but that API is/should be protected. If we want to list IdPs *before*
authenticating a user, we either need: 1) a new API for listing public IdPs
or 2) a new policy that doesn't protect that API.
Thanks,
Is there a real requirement here for this to be a dynamic listing as opposed to
something that can be edited from the horizon local_settings? There are obvious
use cases for both situations where you want this to be dynamic or you very
carefully want to protect which IdPs are available to log in with and from that
perspective it would be a very unusual API for keystone to have.
My understanding of the current websso design where we always logged in via
/v3/OS-FEDERATION/auth/websso/{protocol} was so that you would run a discovery
page on that address that allowed you to customize which IdPs you exposed
outside of keystone. Personally i don't like this which is what i wrote this
spec[1] was for. However my intention there would have been to manually specify
in the local_settings what IdPs were available and reuse the current horizon
WebSSO drop down box.
Jamie
[1] https://review.openstack.org/#/c/199339/
Steve Martinelli
OpenStack Keystone Core
Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM,
Douglas Fish drf...@us.ibm.com wrote: Hi David,
From: Lance Bragstad lbrags...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 2015/08/04 01:49 PM
Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote:
Hi David, This is a cool looking UI. I've made a minor comment on it in
InVision. I'm curious if this is an implementable idea - does keystone
support large numbers of 3rd party idps? is there an API to retreive the
list of idps or does this require carefully coordinated configuration
between Horizon and Keystone so they both recognize the same list of idps?
There is an API call for getting a list of Identity Providers from Keystone
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers
Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015
06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To:
OpenStack Development Mailing List openstack-dev@lists.openstack.org
Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon]
Federated Login Hi Everyone I have a student building a GUI for
federated login with Horizon. The interface supports both a drop down list
of configured IDPs, and also Type Ahead for massive federations with
hundreds of IdPs. Screenshots are visible in InVision here
https://invis.io/HQ3QN2123 All comments on the design are appreciated.
You can make them directly to the screens via InVision Regards
David
__
OpenStack Development Mailing List (not for usage questions) Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions) Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi David, There was a similar effort in Kilo to design the flow in the login page for federated login[1]. WebSSO feature[2] was implemented in Kilo, it allows the user to perform federated login by selecting an IdP protocol. This have tested with kerberos and saml2. There is a proposal to extend that feature to show listing per Idp/Protocol instead [3], because just listing only by protocol is fairly limited . I think the Type Ahead can fit it nicely when we implement the support for WebSSO by IdP/Protocol. thanks, Lin [1] https://openstack.invisionapp.com/d/main#/projects/2784587 [2] http://docs.openstack.org/developer/keystone/extensions/websso.html [3] https://review.openstack.org/#/c/199339/ https://review.openstack.org/#/c/199339/ On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new policy that doesn't protect that API. Thanks, Steve Martinelli OpenStack Keystone Core From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/08/04 01:49 PM Subject:Re: [openstack-dev] [Keystone] [Horizon] Federated Login On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drf...@us.ibm.com wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? There is an API call for getting a list of Identity Providers from Keystone http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi Doug On 04/08/2015 16:52, Douglas Fish wrote: Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. thanks I'm curious if this is an implementable idea It has to be, since there are many existing federations with 100s of IDPs. Simply displaying a list is not usable in this environment. There are many SPs that implement this sort of interface today. Eg. the UK Access Management federation has hundreds of members, see http://www.ukfederation.org.uk/content/Documents/MemberList - does keystone support large numbers of 3rd party idps? It should. I dont know of anyone who has done scalability testing, but I dont think the design has any inbuilt constraints is there an API to retreive the list of idps yes or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? No, Horizon uses the Keystone API regards David Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Horizon] Federated Login
Hi David, This is a cool looking UI. I've made a minor comment on it in InVision. I'm curious if this is an implementable idea - does keystone support large numbers of 3rd party idps? is there an API to retreive the list of idps or does this require carefully coordinated configuration between Horizon and Keystone so they both recognize the same list of idps? Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/01/2015 06:05 AM Subject: [openstack-dev] [Keystone] [Horizon] Federated Login Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] [Horizon] Federated Login
Hi Everyone I have a student building a GUI for federated login with Horizon. The interface supports both a drop down list of configured IDPs, and also Type Ahead for massive federations with hundreds of IdPs. Screenshots are visible in InVision here https://invis.io/HQ3QN2123 All comments on the design are appreciated. You can make them directly to the screens via InVision Regards David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
