PartnerIdentityProviderConfiguration.Name - how to figure it out?

Hi,

I understand the PartnerIdentityProviderConfiguration.Name property is not arbitrary and should be set to match the issuer property returned by the IdP.

I am not sure though how to get that value for the very first time. I think I understand I can download the IdP metadata and look at the entityID (at least in the case of OneLogin the values match, I don’t even know if it’s a standard?). But I am trying to make our multi-tenant app a SP and as such offer each customer to set up SSO via their own IdP. In order to get things working with the component I need the SSO url (and optionally SLO url) and the IdP certificate, which I will ask the customer. But I also need the name in order to add the configuration to the SAMLController and I cannot figure out how to get that name without asking it to the customer.

I have seen some SSO/SAML wizards out there that only ask for the SSO url and the certificate and nothing more so it must be possible, but I don’t understand how.

Every SAML message includes an Issuer field which identifies who sent the message.
For example, when an IdP sends a SAML response the Issuer field identifies the IdP.
We use this Issuer field to lookup the SAML configuration by matching on the PartnerIdentityProviderConfiguration.Name property.
The Issuer field will have the same value as the entityID in the SAML metadata, if provided.
The entityID should uniquely identity the identity provider or service provider and we recommend using a URL.
This is why it’s included in the SAML metadata specification.
I’m not sure about other SAML wizards but perhaps they make some assumption about the IdP name based on the SSO URL.
However, the entityID and other configuration information such as the SSO URL can and usually do have different values.
My recommendation is that your customer must provide their entityID, SSO and optional SLO URLs, and certificate.


[quote]
ComponentSpace - 6/20/2017
Every SAML message includes an Issuer field which identifies who sent the message.
For example, when an IdP sends a SAML response the Issuer field identifies the IdP.
We use this Issuer field to lookup the SAML configuration by matching on the PartnerIdentityProviderConfiguration.Name property.
The Issuer field will have the same value as the entityID in the SAML metadata, if provided.
The entityID should uniquely identity the identity provider or service provider and we recommend using a URL.
This is why it's included in the SAML metadata specification.
I'm not sure about other SAML wizards but perhaps they make some assumption about the IdP name based on the SSO URL.
However, the entityID and other configuration information such as the SSO URL can and usually do have different values.
My recommendation is that your customer must provide their entityID, SSO and optional SLO URLs, and certificate.


[/quote]

Alright - thank you.

Since every message from the IdP includes the Issuer field, would it be possible to somehow send a first "fake" message to the IdP to get a response (I imagine an error message) just to get the issuer field?

As far as I can tell from what I have seen from your high level API, it requires the issuer in order to send a message so that does not sound doable but perhaps it is using the low level API?

Thanks

I’m not sure how that would work. The only message the IdP would respond to is a SAML authn request for SP-initiated SSO.
I think the best option is to request the IdP’s entityID.
If they’re familiar with SAML metadata, which is the standard mechanism for conveying configuration information, they will know what the entityID is.
Even if they don’t use SAML metadata, I can’t recall any providers who don’t use an entityID (aka provider name).

[quote]
ComponentSpace - 6/21/2017
I'm not sure how that would work. The only message the IdP would respond to is a SAML authn request for SP-initiated SSO.
I think the best option is to request the IdP's entityID.
If they're familiar with SAML metadata, which is the standard mechanism for conveying configuration information, they will know what the entityID is.
Even if they don't use SAML metadata, I can't recall any providers who don't use an entityID (aka provider name).

[/quote]

I understand I can ask for the EntityID and I will do so if I have to. According to what you're saying and your various pieces of documentation it even makes sense that I ask them to upload the metadata xml file if they have it so I will probably do that too.

However I just wanted to ensure there is no way - even hacky - to get it ourselves, in order to make the client process even simpler. Is it not possible to send an authn request then with fake, hard-coded data that the IdP would respond to?

Thanks

I doubt it very much.
Unless they have your configuration they’ll probably simply display an error page.
If they do have your configuration and can process the SAML authn request they’ll complete SSO and send you back a SAML response.
Even if you could somehow get them to send you an error SAML response you couldn’t rely on this as different IdPs handle errors differently.
In our experience it’s not often you’ll see an error SAML response. ADFS will do this but many IdPs won’t.
My feeling is that, as you have to ask the client for their certificate and SSO/SLO URLs, asking for their entityID as well doesn’t seem too onerous and is quite normal practice.

[quote]
ComponentSpace - 6/21/2017
I doubt it very much.
Unless they have your configuration they'll probably simply display an error page.
If they do have your configuration and can process the SAML authn request they'll complete SSO and send you back a SAML response.
Even if you could somehow get them to send you an error SAML response you couldn't rely on this as different IdPs handle errors differently.
In our experience it's not often you'll see an error SAML response. ADFS will do this but many IdPs won't.
My feeling is that, as you have to ask the client for their certificate and SSO/SLO URLs, asking for their entityID as well doesn't seem too onerous and is quite normal practice.
[/quote]

I am ok with it, I'm just really curious as to how some SPs I have checked manage to do with only asking the SSO URL and certificate.

For now I will ask for the entityID and/or the full metadata file.

Thanks for your responses!

You’re welcome.