IdP-to-IdP Federation/Proxying TO a Shibboleth IdP?

Cantor, Scott cantor.2 at osu.edu
Mon Apr 7 18:13:17 UTC 2025


> I'm trying to just start "simple" initially...

"Testing" anything in the SSO world is harder than solving an actual concrete problem. It's too artifical and none of the details are real, so people start taking shortcuts (e.g. localhost) and the whole exercise is harder than if it were just done for real up front with specific questions that have to be answered.

>  I just want to be able send a request to the SP side, and then
> get the authentication to occur at the Shibboleth IdP, etc.

That's kind of the literal definition of a SAML SP, or more to the point, you need an application in the first place that is being protected with one. Until you have one, you'll be floundering around.

An IdP isn't a stand alone thing that you can talk to in general, so connecting an IdP to another IdP is not a problem you can tackle easily unless that second IdP already has SPs in its "stable" that are relying on it. They make the requests.

> Is there a KB article that I missed that describes what I would
> need to do that?

The documentation was couched around having an understanding of SAML and SSO systems so that the questions are concretely "how do I solve the usual problems of X, Y, and Z in this software?". It's not documented from a starting from scratch perspective. That issue, if it's ever solved, won't get solved quickly (it's been 20 years, still not solved).

> Or, is it really as simple as something like
> just exchanging the 2 IdP(s) metadata? 

90% of the operation of the software is exchange of metadata, which we solve in our community with third party federations that do all the hard work for us. Within an enterprise, many of us just script all the metadata behind the scemes because the SPs we deal with don't understand metadata anyway.

The rest of the IdP's operation requires a concrete infrastructure supplying authentication, attribute data, etc. Mocking that is harder IMHO than dealing with a real set of requirements in an organization and just dealing with them one at a time. At least I have always found that to be the case.

-- Scott




More information about the users mailing list