First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
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 .
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.
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
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
Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
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
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
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.
at the end of step 4 and use that to get a scoped token.
OpenStack-dev mailing list