<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>I don't think that describes the ideas very fairly, but I'm sorry if that's all it looks like.<br>
<br>
Semt frim mt iPone</div>
<div><br>
On Dec 20, 2016, at 12:26, IAM David Bantz <<a href="mailto:dabantz@alaska.edu">dabantz@alaska.edu</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<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>
</div>
</blockquote>
<blockquote type="cite">
<div><span>-- </span><br>
<span>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">
users-unsubscribe@shibboleth.net</a></span></div>
</blockquote>
</body>
</html>