<div dir="ltr">I empathize with the problem description; I face analogous if smaller scale issues at UA.<div>I'm not at all clear why Shibb 1 + back channel + deprecation of PKI solves the problem.</div><div><br></div><div>David Bantz</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 20, 2016 at 10:54 AM, Klingenstein, Nate <span dir="ltr"><<a href="mailto:nklingenstein@calstate.edu" target="_blank">nklingenstein@calstate.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
<a href="http://simplesso.io/" rel="noreferrer" target="_blank">http://simplesso.io/</a><br>
<br>
The California State University is composed of 23 campuses.  We've operated successful federated identity for a long time.<br>
<br>
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:<br>
<br>
1)  The ingress URL(e.g. IdP metadata) is not always owned by the organization itself<br>
2)  The organization rarely has a credible plan to change IdP's or improve service ever again<br>
3)  It's just a matter of time before an IDaaS sells itself as a service's "preferred" login approach, with greater, proprietary functionality<br>
<br>
Those concerns carry very little water in today's arguments.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I blame the sordid state of federated identity for this.  We can build better than endless layers of profiles.<br>
<br>
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.<br>
<br>
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.<br>
<br>
All feedback anywhere welcome.  The initial idea's done now.  This is the last incarnation.<br>
<br>
<a href="http://simplesso.io/" rel="noreferrer" target="_blank">http://simplesso.io/</a><br>
<br>
Take care,<br>
Nate.<br>
<span class="HOEnZb"><font color="#888888">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>