simpleSSO

[Klingenstein, Nate]

I don't think that describes the ideas very fairly, but I'm sorry if that's all it looks like.

Semt frim mt iPone

On Dec 20, 2016, at 12:26, IAM David Bantz <dabantz at alaska.edu<mailto:dabantz at alaska.edu>> wrote:

I empathize with the problem description; I face analogous if smaller scale issues at UA.
I'm not at all clear why Shibb 1 + back channel + deprecation of PKI solves the problem.

David Bantz

On Tue, Dec 20, 2016 at 10:54 AM, Klingenstein, Nate <nklingenstein at calstate.edu<mailto:nklingenstein at calstate.edu>> wrote:
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.
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161220/c809215d/attachment-0001.html>