Open Stack

On 17/09/2014 16:53, 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.

Our modification to Horizon uses WebSSO since this is the obvious
profile for a browser to use as it can handle redirects automatically.

Your modification for Keystone client uses ECP which is the obvious one
for this to use, as redirects are not required.

However, we also have a mod for Keystone client which uses WebSSO, in
case this is all the keystone server supports

regards

David

> 
> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>