Monday, November 26, 2012

The case for & against embedded browsers for native client authentication

Box makes available a very slick desktop sync agent. In addition to a password based authentication mechanism (relevant to consumers), the agent also supports SSO for enterprise customer employees. 

Disclaimer - Box uses Ping software to make the SSO happen.

Once installed, I need to connect it to my enterprise identity. 

Below is the login UI.


On clicking on the 'Use Single Sign On' link, the screen toggles to eliminate the password form field. (and every password form field eliminated means that both a) a kitten is saved and b) the terrorists lose)




When I clock on 'Continue' on the above, the Box agent opens a browser window, loading a login page hosted by Ping (my enterprise). As soon as I authenticate to this page, Ping will send a SAML assertion attesting to my identity back to Box, for it to then accept as proof of my identity rather than via a password. Based on this authentication Box will send a (different) token down to the agent, this then used on API calls against the Box endpoints.

But, because the browser in which I am asked to authenticate to Ping is embedded within the agent (ie its not my default desktop browser), my Ping AD password (which I've stored in the default browser) is not available.

So I get an empty login form to fill.



My AD password is an incredibly long, complex, and random string Password1 and is not one I have remembered. Consequently, to authenticate in this window, I have to go to that default browser and manually retrieve my Ping password from its store. Not a huge effort, and one that happens only once (or at most infrequently) but still less than optimal.

If the Box agent had instead opened the login page in my default browser, the sequence would have been a bit smoother. The downside (and the reason why I expect Box chose the model they did) is that the parameter passing between the default browser and the Box agent (necessary to deliver the second token to that agent for use on API calls) is more complicated than when the browser is embedded. For mobile OSs, use of a custom scheme URL gets you around this. Is there nothing comparable on desktop OSs?

1 comment:

Travis Spencer said...

The same sort of thing that can be done on mobile is also possible on desktops:

* http://people.w3.org/~dom/archives/2005/09/integrating-a-new-uris-scheme-handler-to-gnome-and-firefox/

* http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx

* etc.