Is it possible to create a single metadata to all IDP providers?

[christian-hawk]

Hello, I have several providers and creating a single metadata for all IDP providers makes more sense. I couldn't find information about it thou, can you help me?

[cjbarth]

@christian-hawk I don't think you'd want that because no IdP would be able to import that. What would you envision this looks like and how would you use it?

[christian-hawk]

Maybe I did the wrong question, sorry @cjbarth .
What I would like to achieve is to generate one single metadata containing all (passport) providers for many (external) IDPs.

[christian-hawk]

Basically I have this single SP providing same metadata for several (n) IDPs. It's an 1-to-n thing.

I was checking out MultiSamlStrategy but it's not clear for me if I can create 1 single metadata to all external IDPs.

[gugu]

Are you sure it is possible in the SAML protocol? You can generate metadata in a loop for every SAML provider and combine these strings somehow, but as far as I know there is no standard for this

[christian-hawk]

@gugu thanks for your quick reply.

What I need to achieve (if possible) is that all my IDP peers would use the same Assertion Consumer Service (ACS) endpoint at passport, and a single metadata url. Further routing of incoming SAML responses would happen internally, like it’s done by most other SAMP SP implementations (Shibboleth SP, for example). As currently I basically have a separate SP for every IDP registered in Passport.

When you ask if I'm sure if it's possible, I can tell you it's possible because it's a common practice, but I will have to check some specs to bring you more solid information. Hope the above rephrasing helps.

Thanks again 👍🏻

[srd90]

It seems that this passport-saml issue's roots and actual business case issue was old issue at GluuFederation/gluu-passport repository and later that particular issue https://github.com/GluuFederation/inbound-saml/issues/1 triggered creation of GluuFederation/inbound-saml repository and it became first issue of that repository.

I wrote this comment so that whoever looks this issue in the future could take a look at how @christian-hawk implemented this at aforementioned repository (note: its license is Apache 2.0 and passport-saml's is MIT) in order to evaluate how much effort it would take to port it here (if it is even possible from license and technical aspects point of view) and what corner cases there might exists.