Open Stack

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