Open Stack

Adam
I agree with you
David

On 18/09/2014 17:17, Adam Young wrote:
> 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>