On 08/06/2015 07:09 PM, Dolph Mathews wrote:
On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
<[email protected] <mailto:[email protected]>> wrote:
On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
<[email protected] <mailto:[email protected]>> wrote:
----- Original Message -----
> From: "David Lyle" <[email protected]
<mailto:[email protected]>>
> To: "OpenStack Development Mailing List (not for usage
questions)" <[email protected]
<mailto:[email protected]>>
> 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 <
[email protected] <mailto:[email protected]> >
> wrote:
>
>
>
> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
[email protected] <mailto:[email protected]> >
> 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 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 < [email protected]
<mailto:[email protected]> > wrote:
>
> From: Dolph Mathews < [email protected]
<mailto:[email protected]> >
> To: "OpenStack Development Mailing List (not for usage
questions)" <
> [email protected]
<mailto:[email protected]> >
> 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 <
[email protected] <mailto:[email protected]> >
> 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
<[email protected] Bragstad >
> ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52
AM, Douglas > Fish
> < [email protected] <mailto:[email protected]> > wrote:
> Hi David, > > From: Lance Bragstad <
> [email protected] <mailto:[email protected]> > > To:
"OpenStack Development Mailing List (not for
> usage questions)" > < [email protected]
<mailto:[email protected]> > > 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
> <[email protected]_ > <mailto: [email protected]
<mailto:[email protected]> >> 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
<[email protected]_ > <mailto:
> [email protected] <mailto:[email protected]>
>> wrote on 08/01/2015 06:01:48 AM: > > > From:
> David Chadwick <[email protected]_ > <mailto:
[email protected] <mailto:[email protected]>
> >> > > To: OpenStack Development Mailing List >
> <[email protected]_ > <mailto:
> [email protected]
<mailto:[email protected]> >> > > 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:_ > __
>[email protected]?subject:unsubscribe_
<http://[email protected]?subject:unsubscribe_>
> <
>
http://[email protected]?subject:unsubscribe
> > > _
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
> > > > >
>
__________________________________________________________________________
>
> OpenStack Development Mailing List (not for usage
questions) > Unsubscribe:
> > _
[email protected]?subject:unsubscribe_
<http://[email protected]?subject:unsubscribe_>
> <
>
http://[email protected]?subject:unsubscribe
>_ > __
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
> >
>
__________________________________________________________________________
>
> OpenStack Development Mailing List (not for usage
questions) > Unsubscribe:
>
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > >
>
__________________________________________________________________________
>
> OpenStack Development Mailing List (not for usage
questions) > Unsubscribe:
>
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage
questions) Unsubscribe:
>
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
