determine fidp from Issuer in IdP-initiated SAML2

[hauntingEcho]

Currently, IdP-initiated SAML2 is not supported for configured IdPs. However, there is an ability to trigger the SP-initiated flow against IdP x by hitting /samlsso?fidp=x.

Enabling the /commonauth endpoint to determine the correct fidp from the Issuer present in the SAML2 message would:

• allow much simpler configuration of the federated IdPs
• remove the need to provide separate configuration metadata, with differing fidp parameters, to each.

[thanujalk]

@hauntingEcho There are few things need to be clarified about this requirement.

1. fidp parameter is used to directly redirect the end-user to the IdP, rather than showing the multi-option page. Do you multiple IdPs configured for your SP?
2. For an SP We can configure only one issuer name. If the IdP differ based only on the issuer name, why can't we configure only one IdP for the SP? What is the requirement of having fidp value?

Can you please clarify your requirements further?

[hauntingEcho]

We are using wso2is as an identity bus - our SaaS receives mapped local subject identifiers from WSO2IS, which in turn handles users from multiple identity providers.

For clarity, I was referring to the 'issuer' present in the SAML2 message received from the IdP, which is the IdP's issuer name. Any SP's issuer name is unrelated. The currently-possible SP-initiated flow which I had mentioned was between WSO2IS (as the SP) and the configured Identity Provider, which requires the fidp parameter in order to select the right identity provider rather than just accepting a posted saml2 assertion and determining who sent it by its contents.

[hauntingEcho]

An example for further clarity:

• two connected instances of WSO2IS via these instructions: https://docs.wso2.com/display/IS560/Log+in+to+the+Identity+Server+using+another+Identity+Server+-+SAML2
• using those same instructions, 'primary' is connected to another WSO2IS instance Idp. Lets' call it 'otherIdp'.
• 'primary' is connected to a service provider, lets' call it "SP", which is configured to take 1-step authentication from either 'secondary' or 'tertiary' and allows IdP-intiated login via the mapped local subject identifier
• for ease of use, assume everything is on localhost with primary on port 9443, secondary on port 9444, and otherIdp on port 9445.

currently, for IdP-initiated login, 'secondary' must be given the ACS "https://localhost:9443?fidp=secondary&spEntityID=SP" and "otherIdp" must be given "https://localhost:9443?fidp=otherIdp&spEntityID=SP" in order to skip making the user choose the right IdP. This means that a different metadata file would need to be manually created for each IDP to be configured.

However, in the IdP-initiated SAML flow, OtherIdp is already posting a SAML2 message with <issuer>otherIdp</issuer> and Secondary is already posting a SAML2 message with <issuer>secondary</issuer>. By using this field, the fidp parameter becomes unnecessary and configuration becomes more reusable. The X509Certificate field can also be used for differentiation in messages with signed elements.

[thanujalk]

@hauntingEcho Thanks for the detailed clarification. Yes, for the federated IdP initiated SSO case, fidp parameter is redundant.