Support for using multiple IdPs concurrently

[madsfreek]

In the WAYF.dk federation it is quite common for our users to use at least two IdPs for different services. Typically one of the IdPs is the Danish government IdP (NemLog-in) and the other an institutional IdP. The main reason for the daily use of NemLog-in (in addition to the occasional use of it for institutional id booting and password reset) is that quite often the institutions student information systems and their identity management systems are not integrated, so our national id number (cpr) is used in the SIS and are provisioned as the primary key in SIS data to internal and external systems. Thus the users are able/forced to log in using NemLog-in which provides cpr.

We therefore currently keep SP/IdP pairs in our persistence layer and have built our RA21 button support on top of that. This allows us to present a SP specific IdP on the button. We would like to use the seamless.org persistence layer eventually, but we need support for this use case.

In the current implementation of thiss.js our users will experience a lot of flip-flop as the button (depending on the algorithm for selecting the IdP) always shows the last used IdP?

We have an additional challenge in that our entities can belong to multiple tagged sub-federations and they are only allowed to communicate if the intersection of the SP's and IdP's tags are not empty. Our current discoveryservice checks for that - it knows the SP - and doesn't show irrelevant IdP apart from previously choosen IdP which are marked as irrelevant.

As thiss.js uses a self-declared "RequestInitiator" (loginInitiatorURL) it doesn't actually know the SP
and even if it did this check would potentially require a metadata lookup if the SP metadata wasn't cached and I understand that might be to heavy for the button.

Using the SP entityID as a parameter to the button would require that the loginInitiatorURL could be validated in SP metadata to prevent leaking IdP information so this seems out of the question as well.

However I have an early version (not based on thiss code!) running that uses the same list of IdPs as thiss.js, but in addition keeps a map of loginInitiatorURLs to IdP entityIDs pairs.

A pair is added to the map for every used loginInitiatorURL/IdP pair and if an IdP is removed from the DS all pairs with that IdP is deleted as well.

Although not fully tested yet it seems to fulfill our reqirements without adding too much complexity to thiss.js?

[leifj]

We discussed this briefly in NOLA. We agree that we probably can implement this but that it requires the new authz model where we can stick the SP entityID in the response JWT token.This eliminates the need for fancy footwork for the loginInitiatorURL and metadata