Comment 3 for bug 1472060

Hi,

As a matter of fact remote_ids should be tied to the IdP object in Keystone from the very beginning. It's Apache that can diferentiate who issed this particular assertion, but without remote_id keystone couldn't verify what was originating IdP. Keystone was choosing mappings based on user sayning "I want to use IdP X and protocol Y". In fact, user could be authenticated by IdP Z but say "I am comming from IdP X" just by building the link. with remote_id, being part of the assertion keystone can now verify such situations.

WebSSO has one static URL to be used (/OS-FEDERATION/websso/{protocol}) because IdP name is completely random and keystone specific (whatever admin configured via v3 API) and you don't want Horizon to build dynamic URLs. Unlike CLI access (via ECP) WebSSO has a powerful mechanism for discovering against which IdP you want to authenticate. In CLI you must rather know this apriori (client must specify that)

When it comes to CLI access there are cases where (for instance that's how MS ADFS is implemented) you start by authenticating with IdP and only after going to SP with a ready to be used assertion. I am trying to recall whether we had some more specific rationale for keeping idp/protocol in the URL, but I now think it was just because we would have to change everything again.

Also, I don't thing Horizon should be a source of available IdPs - this should be managed by Keystone at most.