Open Stack

Hi,

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

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

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