On 09/17/2014 11:53 AM, Marek Denis wrote:
Hi,

First of all, we should clarify whether your JS client wants to implement ECP or WebSSO workflow. They are slightly different.

ECP seems to be poorly supported in live deployments, and we cannot count on it. WebSSO is the first round. We should do ECP as a second step.


I feel JS is smart enough to implement the ECP flow and then and it could simply implement what we already have in the keystoneclient [0]. This + some "discovery service" described by Adam would be required. However, some problems may arise when it comes to ADFS support (we needed separate plugin in keystoneclient) and other protocols which should work by default from browsers.

[0] https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29

Rest of the comments inlined.

On 17.09.2014 17:00, Adam Young wrote:
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"

Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
Right.  That is a feature request.



4. User clicks OK.

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.

Let's assume this step would work for now. I am interested how would the SP-IDP-SP workflow look like from the JS perspective. In classic WebSSO, where user uses only his browser:

1) Go to the protected resource (/v3/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth in our case)

2) (skipping the DS step for now) get redirected to the IdP
3) Authenticate with the IdP
4) Get redirected to the SP
5) Read your protected content, because you have been authenticated and authorized to do so (get an unscoped, federated token issued by Keystone in our case)

Now, I can imagine, if that's the websso approach can we somehow make JS mimic the browser with all its blessing? So the user would actualy see the real HTML website? If so, that would be enough to make it work.
I think that we need to show the user the real website in a Popup window until we have a guarantee of ECP support.


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.

_______________________________________________
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