Open Stack

On 10/08/2015 01:53, Jamie Lennox wrote:
> 
> 
> ----- Original Message -----
>> From: "David Chadwick" <d.w.chadwick at kent.ac.uk> To:
>> openstack-dev at 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.mathews at gmail.com>
>>> *To: *"OpenStack Development Mailing List (not for usage
>>> questions)" <openstack-dev at 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
>>> <lbragstad at gmail.com <mailto:lbragstad at gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews 
>>> <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>>
>>> wrote:
>>> 
>>> 
>>> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox 
>>> <jamielennox at redhat.com <mailto:jamielennox at redhat.com>> wrote:
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "David Lyle" <dklyle0 at gmail.com 
>>>> <mailto:dklyle0 at gmail.com>> To: "OpenStack Development Mailing
>>>> List (not for usage questions)"
>>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at 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.mathews at gmail.com <mailto:dolph.mathews at gmail.com>
>>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < 
>>>> stevemar at ca.ibm.com <mailto:stevemar at 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").
>>> 
>>> 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 to: 
>>> https://keystone.example.com:5000/v3/OS-FEDERATION/websso/saml 
>>> (where saml is the protocol from above) * On this page if you are
>>> cern/kent and have hundreds of IdPs you show a discovery page to
>>> pick the one you want, and get redirected to the actual login
>>> page. * On returning to keystone from login you have the
>>> remote_url of the page you logged in with. Keystone consults the
>>> remote_id parameter of each idp and FROM THAT URL DETERMINES
>>> WHICH KEYSTONE IDP WE USE. * Keystone uses that idp, the protocol
>>> mentioned earlier, determines the mapping, and maps variables. *
>>> Keystone then redirects a new token back to horizon.
>>> 
>>> For an example of this see the talk i did last weekend: 
>>> https://youtu.be/YYzJdxI_g6g
>>> 
>>> So as you might have seen from the CAPS there is currently no
>>> mechanism for django_openstack_auth to indicate to keystone which
>>> IdP the user selected from a drop down list, only a protocol. I
>>> find this absurd and so wrote a spec:
>>> https://review.openstack.org/#/c/199339/
>>> 
>>> I agree otherwise on the basics of this thread. I'm just haven't
>>> seen a plan yet on how anyone expects to implement this horizon
>>> based selection with the current implementation.
>>> 
>>> 
>>> 
>>> @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.chadwick at kent.ac.uk 
>>>> <mailto:d.w.chadwick at kent.ac.uk> wrote:
>>>> 
>>>> From: Dolph Mathews < dolph.mathews at gmail.com 
>>>> <mailto:dolph.mathews at gmail.com> > To: "OpenStack Development
>>>> Mailing List (not for usage questions)" < 
>>>> openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at 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.chadwick at kent.ac.uk <mailto:d.w.chadwick at 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 at us.iLance Bragstad >
>>>> ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at
>>> 10:52 AM, Douglas > Fish
>>>> < drfish at us.ibm.com <mailto:drfish at us.ibm.com> >
>>> wrote: > Hi David, > > From: Lance Bragstad <
>>>> lbragstad at gmail.com <mailto:lbragstad at gmail.com> > >
>>> To: "OpenStack Development Mailing List (not for
>>>> usage questions)" > <
>>> openstack-dev at lists.openstack.org 
>>> <mailto:openstack-dev at 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
>>>> <_drfish at us.ibm.com_ > <mailto: drfish at us.ibm.com
>>> <mailto:drfish at 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.chadwick at kent.ac.uk_ > <mailto:
>>>> d.w.chadwick at kent.ac.uk
>>> <mailto:d.w.chadwick at kent.ac.uk> >> wrote on 08/01/2015 06:01:48
>>> AM: > > > From:
>>>> David Chadwick <_d.w.chadwick at kent.ac.uk_ > <mailto:
>>> d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>
>>>>>>>> To: OpenStack Development Mailing List >
>>>> <_openstack-dev at lists.openstack.org_ > <mailto: 
>>>> openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe_
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>
>>>
>>> 
> <
>>>> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe_ 
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>
>>>
>>> 
> <
>>>> 
>>> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
>>> <http://OpenStack-dev-request@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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>