websso callback is in the wrong place

[Jamie Lennox]

We have all this infrastructure in /OS-FEDERATION/identity_providers/{id}/protocol/{id} to uniquely identify the relationship between an identity provider and a protocol for interacting with that provider so we can apply mappings. With websso we then hard code a route of /OS-FEDERATION/websso/{protocol}. Because we have just stripped the identity_provider from the URL we then have to add remote_ids to the identity_providers so that the websso/protocol route can figure out which idp we are talking about and lookup the idp.

We have a route that includes the idp id and protocol and if we had put the websso route at /OS-FEDERATION/identity_providers/{id}/protocol/{id}/websso (next to where /auth) lives we wouldn't need the multiple <location>s in the httpd config and we wouldn't need to add remote_ids to the idp (because we've already established this once in httpd).

I'm sure there are advantages to this too but what was the point of /identity_providers/{id}/protocol/{id} if we're going to have to establish remote_id relationships back to and IDP?

</rant>

[Steve Martinelli (stevemar)]

people were stating that listing all IdPs through horizons login page was insecure, leveraging remote_id was the only way we programatically determine the idp that was being used

[Jamie Lennox (jamielennox)]

You wouldn't necessarily automatically add all the IDPs to the horizon login page. When you specify the WEBSSO_CHOICES in django_openstack_auth you would have the websso endpoint associated with that drop down value.

[Marek Denis (marek-denis)]

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.

[Jamie Lennox (jamielennox)]

So you're saying that remote_id is correct and that we should never have bothered with identity_provider/{id}/protocol/{id}? just have one entry point for protocol and lookup idp from within there?

IdP name is random but what i'm saying is you already provide options when you do WEBSSO_CHOICES in horizon. That this could have easily included a link to the websso address to use for that specific provider for example:

WEBSSO_CHOICES = (
    _("Corporate Identity"), "https://path/to/keystone/identity_provider/ABCD/protocol/saml2/websso",
    _("Google"), "https://path/to/keystone/identity_provider/EFGH/protocol/saml2/websso"
)

As you provide additional SAML sources you continue to provide the links to their websso specific URLs.

Note: you wouldn't have to use the whole url like that as horizon only needs to know how to talk to keystone so you would just need to provide the idp_id and the protocol

Can you explain how you could provide incorrect assertions to different IDPs? When you setup an IDP in httpd you have to link to a copy of the metadata for that IDP which includes the signature of the IDP that will have signed the assertions. If you provide a different assertion to another IDP then the signature validation will fail.