simpleSSO

[Klingenstein, Nate]

All,

http://simplesso.io/

The California State University is composed of 23 campuses.  We've operated successful federated identity for a long time.

IDaaS has strong traction at a number of campuses.  While I'm agnostic on IDaaS as an idea, I have three concerns about today's editions:

1)  The ingress URL(e.g. IdP metadata) is not always owned by the organization itself
2)  The organization rarely has a credible plan to change IdP's or improve service ever again
3)  It's just a matter of time before an IDaaS sells itself as a service's "preferred" login approach, with greater, proprietary functionality

Those concerns carry very little water in today's arguments.

Further, I'm having a hard time convincing vendors to implement SAML, and the ones that have implemented SAML result in minimal interoperability as they interpret and implement a complex standard.

I now have campuses that demand use of InCommon and others that demand use of Okta and Azure AD.  I can bridge or proxy these environments in some ways, and that way lies madness.  I'd rather not build a worse world, yet the CSU is faced with paying companies to build SAML-to-SAML proxies at this point.

I blame the sordid state of federated identity for this.  We can build better than endless layers of profiles.

I've worked up an alternative, dirt-simple federated identity protocol based on Shibboleth 1.0 called simpleSSO.  Several small tweaks lead to new capability.

Rather than tokens, there are federated sessions.  Signature and encryption are replaced by back-channel queries.  I don't think separate SP implementation will usually be needed, and libraries are more of a convenience than a necessity.  It's pretty dumb, fails closed, and is hard to screw up.

All feedback anywhere welcome.  The initial idea's done now.  This is the last incarnation.

http://simplesso.io/

Take care,
Nate.