<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
----- Original Message -----<br>
> From: "David Lyle" <<a href="mailto:dklyle0@gmail.com" target="_blank">dklyle0@gmail.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</span><span>> Sent: Thursday, August 6, 2015 5:52:40 AM<br>
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login<br>
><br>
</span><span>> Forcing Horizon to duplicate Keystone settings just makes everything much<br>
> harder to configure and much more fragile. Exposing whitelisted, or all,<br>
> IdPs makes much more sense.<br>
><br>
> On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews < <a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < <a href="mailto:stevemar@ca.ibm.com" target="_blank">stevemar@ca.ibm.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> Some folks said that they'd prefer not to list all associated idps, which i<br>
> can understand.<br>
> Why?<br>
<br>
</span>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 <a href="http://COKE.COM" rel="noreferrer" target="_blank">COKE.COM</a> domain and i can see for example that <a href="http://PEPSI.COM" rel="noreferrer" target="_blank">PEPSI.COM</a> 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.<br>
<br>
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 <a href="http://COKE.COM" rel="noreferrer" target="_blank">COKE.COM</a> 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 <a href="http://COKE.COM" rel="noreferrer" target="_blank">COKE.COM</a> is going to allow.<br>
<br>
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.<br></blockquote><div><br></div></span><div>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:</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div></span><div>The user would be required to know the id of the IdP in which they want to federate with, right? </div><div><div><div> </div></div></div></div></div></div></blockquote><div><br></div></span><div>As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like <a href="http://customer-x.cloud.example.com/" target="_blank">http://customer-x.cloud.example.com/</a> or <a href="http://cloud.example.com/customer-x" target="_blank">http://cloud.example.com/customer-x</a>) that I need to know to kickoff the correct federated handshake with my IdP using a single button press ("Login").</div></div></div></div></blockquote><div><br></div><div>The benefit of the first example is that I can easily setup DNS to redirect <a href="http://cloud.customer-x.com">cloud.customer-x.com</a> to <a href="http://customer-x.cloud.example.com">customer-x.cloud.example.com</a>, where <a href="http://example.com">example.com</a> is my public cloud provider. The benefit of the second example is that it's completely trivial for the public cloud provider to implement.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>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.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
@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.<br>
<br>
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.<br>
<br>
<br>
Jamie<br>
<span><br>
><br>
><br>
><br>
><br>
><br>
> Actually, I like jamie's suggestion of just making horizon a bit smarter, and<br>
> expecting the values in the horizon settings (idp+protocol)<br>
> But, it's already in keystone.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Steve Martinelli<br>
> OpenStack Keystone Core<br>
><br>
</span><span>> Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM,<br>
> David Chadwick < <a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a> > wrote:<br>
><br>
> From: Dolph Mathews < <a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a> ><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<br>
> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a> ><br>
> Date: 2015/08/05 01:38 PM<br>
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login<br>
><br>
><br>
><br>
><br>
><br>
</span><div><div>> On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick < <a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a> ><br>
> wrote:<br>
><br>
> On 04/08/2015 18:59, Steve Martinelli wrote: > Right, but that API is/should<br>
> be protected. If we want to list IdPs > *before* authenticating a user, we<br>
> either need: 1) a new API for listing > public IdPs or 2) a new policy that<br>
> doesn't protect that API. Hi Steve yes this was my understanding of the<br>
> discussion that took place many months ago. I had assumed (wrongly) that<br>
> something had been done about it, but I guess from your message that we are<br>
> no further forward on this Actually 2) above might be better reworded as - a<br>
> new policy/engine that allows public access to be a bona fide policy rule<br>
> The existing policy simply seems wrong. Why protect the list of IdPs?<br>
><br>
><br>
> regards David > > Thanks, > > Steve Martinelli > OpenStack Keystone Core > ><br>
> Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29 PM---On ><br>
> Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish <drfish@us.iLance Bragstad ><br>
> ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas > Fish<br>
> < <a href="mailto:drfish@us.ibm.com" target="_blank">drfish@us.ibm.com</a> > wrote: > Hi David, > > From: Lance Bragstad <<br>
> <a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a> > > To: "OpenStack Development Mailing List (not for<br>
> usage questions)" > < <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a> > > Date: 2015/08/04<br>
> 01:49 PM > Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login<br>
> > > ------------------------------------------------------------------------<br>
> > > > > > > On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish<br>
> <_drfish@us.ibm.com_ > <mailto: <a href="mailto:drfish@us.ibm.com" target="_blank">drfish@us.ibm.com</a> >> wrote: > > Hi David, ><br>
> > This is a cool looking UI. I've made a minor comment on it in InVision. ><br>
> > I'm curious if this is an implementable idea - does keystone support ><br>
> large > numbers of 3rd party idps? is there an API to retreive the list of ><br>
> idps or > does this require carefully coordinated configuration between ><br>
> Horizon and > Keystone so they both recognize the same list of idps? > > ><br>
> There is an API call for getting a list of Identity Providers from Keystone<br>
> > > _<br>
> <a href="http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_</a><br>
> > > > > Doug Fish > > > David Chadwick <_d.w.chadwick@kent.ac.uk_ > <mailto:<br>
> <a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a> >> wrote on 08/01/2015 06:01:48 AM: > > > From:<br>
> David Chadwick <_d.w.chadwick@kent.ac.uk_ > <mailto: <a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a><br>
> >> > > To: OpenStack Development Mailing List ><br>
> <_openstack-dev@lists.openstack.org_ > <mailto:<br>
> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a> >> > > Date: 08/01/2015 06:05 AM > ><br>
> Subject: [openstack-dev] [Keystone] [Horizon] Federated Login > > > > Hi<br>
> Everyone > > > > I have a student building a GUI for federated login with<br>
> Horizon. The > > interface supports both a drop down list of configured<br>
> IDPs, and also > > Type Ahead for massive federations with hundreds of IdPs.<br>
> Screenshots > > are visible in InVision here > > > > _<br>
> <a href="https://invis.io/HQ3QN2123_" rel="noreferrer" target="_blank">https://invis.io/HQ3QN2123_</a> > > > > All comments on the design are<br>
> appreciated. You can make them directly > > to the screens via InVision > ><br>
> > > Regards > > > > David > > > > > > > > ><br>
> __________________________________________________________________________ ><br>
> > OpenStack Development Mailing List (not for usage questions) > ><br>
> Unsubscribe:_ > __<br>
</div></div><span>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_</a> > <<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> > > > _<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_</a> > > > > ><br>
> __________________________________________________________________________ ><br>
> OpenStack Development Mailing List (not for usage questions) > Unsubscribe:<br>
</span>> > _ <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_</a> > <<br>
<div><div>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> >_ > __<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_</a> > ><br>
> __________________________________________________________________________ ><br>
> OpenStack Development Mailing List (not for usage questions) > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a> > > > > ><br>
> __________________________________________________________________________ ><br>
> OpenStack Development Mailing List (not for usage questions) > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a> ><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>