Saml integration

[the-overengineer]

Implements the SAML flow for traditional websites. The URL is built on-demand (to keep the timestamps current in the JWT) and the user is redirected to the provider, through the usual flow, and back to the configured URL, which then verifies the token and redirects the user appropriately.

All of this happens automatically if web.saml.enabled is set to true in the configuration.

As for the SPA flow, it currently only tosses the provider data in the login form view model, which is the old behaviour. This does not include the idp url generation. @robertjd Should it? To preserve the same behaviour as the traditional websites, it would have to get a fresh token with the redirect URI.

The only idea that comes to mind without adding verification logic to the SPAs is to have the SPA also redirect the user to the /verify page, passing a query parameter so that the /saml-verify endpoint knows to redirect the user back to the SPA.

Alternatively, it could redirect back to the app and have it exchange it via stormpath_token grant, like the Client API social flow. In this case, all express would have to do is generate a fresh token in the initial redirect URL. Not sure what you intend to do with the Client API changes, as well.

This part is still a WIP, obviously.

Also, we talked about route naming, so that's something that ought to be checked.

Fixes #492 (once the SPA part is done)

[coveralls]

Coverage decreased (-1.1%) to 67.428% when pulling 6f56d76fd1dec548fa89f8f10d36485cf58feee0 on saml-integration into 3b242a09b174d4a7e70fb7a9820bc0531703a2ee on master.