zlacker

I'm surprised you'd say SP-side libraries are open source. In my experience, it's always been mostly custom and close source in every company I've seen and done.

You take some open source pieces you can (saml, xml, oidc, ssl, jwt) but permissions, groups, user attributes, keys are always per company then the whole thing together has to be supported into end-user applications running on language and frameworks of the day with their own restrictions, so custom.

>>user59+(OP)
What's the closed-source SAML library you're thinking of? Every SAML integration I've seen has been done with an open-source library.

>>tptace+E3
I mean the company is writing it's own code for a significant part. Let's say one has to integrate SAML/OIDC into a Java app of some sort.

One can find an open source library to handle part of the SAML or XML in Java, but it doesn't take the right settings or import user attributes as needed or handle URL redirections properly. So the company has to write a ton of authentication code to make it work. It may start from an open-source library but the result is either separate code on top or an outright fork.

>>user59+0a
One will find a library to do the SAML. That library will almost certainly do the XML (most likely with xmlsec1). The library will have a call for the ACS endpoint, for the SSO login endpoint, and maybe for the SLO endpoint; it won't implement the endpoints itself, but it'll implement all the logic of the endpoint.

The company will end up writing a ton of authentication and authorization code --- it'll do that no matter what, because the application will have its own security logic, like all applications do.

(OIDC doesn't use XML. But the story is the same, with different endpoints.)