Open Stack

Hi,

----- Original Message -----
> From: "Adam Young" <ayoung at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, September 17, 2014 5:00:16 PM
> Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
> 
> On 09/17/2014 10:35 AM, David Chadwick wrote:
> 
> 
> 
> this would work as well, but wouldn't it require two different API calls?
> 
> I think it would be 2 calls no matter what.
> 
> OK, lets talk this through:
> 
> 1. Configure Horizon to return a generic login page, with a button that says
> "Or do Federated"
> 2. Use clicks that button and gets the Federated UI. No new HTTP request
> needed for this, still just static Javascript. Form has an edit field for
> the user to enter the SAML IdP, anda button to fetch the list of the public
> IdPs from Keystone.
> 3. Assume user clicks the list of public IdPs, those fill out a drop-down
> box. If the user clicks on one, it populates the textbox with the URL for
> the IdP.
> 3a. However, if the users IdP is not in the list, they go back to the email
> they got from their IT guy that has "Paste this URL into the IdP edit box"
> 
> 4. User clicks OK.
> 
> Window pops up with the WebUI for the user to visit the SAML IdP URL. This
> will be of the form
> 
> GET
> htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
> 
> Which will perform the necessary redirects to get the user the SAML
> assertion, and return it to Keystone.
> 
> 5. Javascript picks up the Federated unscoped token from the response at the
> end of step 4 and use that to get a scoped token.
> 

I think the jump to step 6 isn't unnecessary: logging in Horizon requires only a username and a password, 
unless I am wrong scoping is done afterwards by selecting a project in a list. Besides, should we expect
a federated user to necessarily know beforehand to which domain/project she was mapped ?

> 
> 6. Javascript submites the scoped token to Horizon and user is logged in.

Horizon will also need to keep track of the fact that a federated auth was used:

* to list projects and domains available to the user
* to scope the unscoped saml token

As these are done through the federation API rather than the usual one.

> Whew.

Whew indeed ! 

> 
> 
> 
> 
> 
> On 17/09/2014 15:17, Adam Young wrote:
> 
> 
> 
> On 09/17/2014 10:07 AM, David Chadwick wrote:
> 
> 
> 
> On 17/09/2014 14:55, Marek Denis wrote:
> 
> 
> 
> On 17.09.2014 15:45, Steve Martinelli wrote:
> 
> 
> 
> ++ to your suggestion David, I think making the list of trusted IdPs
> publicly available makes sense.
> I think this might be useful in an academic/science world but on the
> other hand most cloud providers from the 'business' world might be very
> reluctant to expose list of their clients for free.
> It is interesting that this latter comment came from the
> academic/science world, whereas the supportive one came from the
> business world :-)
> 
> So maybe there could be a config parameter in keystone to determine
> which option is installed?
> My thought was that there would be a public list, which is a subset of
> the overall list.
> 
> For non-publicized IdPs, the end users would get an URL out of  band and
> enter that in when prompted;  if they enter an invalid URL, they would
> get an warning message.
> 
> It wouldn't hide the fact that a customer was registered with a given
> cloud provider, but wouldn't advertise it, either.
> 
> 
> 
> regards
> 
> David
> 
> 
> 
> cheers,
> 
> Marek.
>