Is it possible to create a single metadata to all IDP providers? #639
-
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? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
@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? |
Beta Was this translation helpful? Give feedback.
-
Maybe I did the wrong question, sorry @cjbarth . |
Beta Was this translation helpful? Give feedback.
-
Basically I have this single SP providing same metadata for several (n) IDPs. It's an 1-to-n thing. I was checking out |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
@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 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
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 GluuFederation/inbound-saml#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. |
Beta Was this translation helpful? Give feedback.
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 GluuFederation/inbound-saml#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 ex…