undefined | Better HN

0 pointsshkkmo8y ago0 comments

Our partners are not commercial SSO systems, nor do they all use commercial SSO systems.

We looked at SAML and it didn't seem to be a good fit for our use case. It is overly complex for our needs.

Instead we built a very small subset of what SAML allows, that is very easy to understand and allows our partners to use lightweight JWT libraries with simple APIs instead of trying to figure out how to get a complex SAML implementation to work with our flow.

We didn't re-invent anything. We used an existing, simpler standard for one of it's intended use cases. Our implentation is < 100 lines of code (not including the JWT library which implements the standard).

Edit:

The relevant SAML flow is this:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-t...

But good luck finding good documentation on it.

0 comments

2 comments · 1 top-level

tptacek8y ago· 1 in thread

The model that you described is, verbatim, the bearer model of SAML that everybody uses. SAML in theory does more than just that, but the flow you just described is the subset of SAML that every open source SAML library implements. Apart from some minor security controls that you didn't describe and that SAML implements, the only difference is that you built your ad hoc system using JWE, and SAML is built with XMLDSIG.

(Responding to edit)

I can only assume that the most widely-used flow in SAML, the dominant SSO protocol on the Internet, is better documented than the ad-hoc custom version of SAML you reimplemented with JWT. :)

I don't like SAML (I in fact hate it), but the problems I have with SAML are all shared by JWE/JWT! You are describing perhaps the one scenario in all of human experience where I might recommend that someone adopt an XMLDSIG protocol.

shkkmoOP8y ago

> I can only assume that the most widely-used flow in SAML, the dominant SSO protocol on the Internet, is better documented than the ad-hoc custom version of SAML you reimplemented with JWT. :)

JWT has much better documentation than anything I was able to find on SAML, but this may be due to my lack of experience with the domain. I had trouble even finding clear documentation on what the basic structure of a SAML assertion should be. As a developer with limited knowledge of the domain, when picking a tool to solve my problem I default to the simpler tool with more accessible documentation.

The documentation for utilizing our JWT implementation is simpler and more straightforward than what Salesforce provides for it's similar flow implemented with SAML.

> the problems I have with SAML are all shared by JWE/JWT!

And what are those? This was my original question.

j / k navigate · click thread line to collapse