Web authentication for SAML federated keystone

If the new SAML federation is enabled in Keystone portals, like
Horizon, cannot anymore use the current mechanism to authenticate the
users but they should use a delegation mechanism.

The SAML ECP profile, currently implemented in Keystone, does not
provide the delegation and almost no IdPs provide support to this
protocol. Moreover, only very few implementations of SAML IdP support
the protocol making difficult for many organisation to provide it.

( https://wiki.shibboleth.net/confluence/display/SHIB2/ECP )

Nevertheless, the authentication is requested only to get the token to
use for the following communications which are not anymore secured
with SAML. As a result, implementing the delegated ECP profile could
be overkill, especially for organisation building their own portal to
access the cloud.

Therefore, to simplify the authentication for web applications,
keystone should act as a proxy. In more detail, during the login
Horizon (or others) redirects the user to keystone for authentication
instead of asking for credentials. Keystone will validate the user
identity and, at the end, sent back the user to horizon with a valid
token.

The mechanism is very similar to OAuth2.0 protocol which aims at
providing a token for the following communications.

Additionally, it could be valuable to enable the user with the ability
to retrieve a token even without horizon starting the authentication
process.

Finally, other federated protocols could use the same approach for web
authentication to limit the use of complex delegated mechanisms.