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