On 09/17/2014 11:56 AM, Matthieu Huin wrote:
Hi,

----- Original Message -----
From: "Adam Young" <ayo...@redhat.com>
To: openstack-dev@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 ?

Think of it this way; today, Horizon uses the userid and password to get a token. In the case where that password is in LDAP, Horizon should never, ever see it. Even Keystone should never see it. So the Token abstracts that away, and says instead "I've checked their password. its good."


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:
Once Horizon has a token, it can do all this. Federation is kindof irrelevant.

* 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.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to