<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 12:50 PM, Bryan E. Wooten <span dir="ltr"><<a href="mailto:bryan.wooten@utah.edu" target="_blank">bryan.wooten@utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the replies.<br>
<br>
You confirmed my thoughts on this. I asked because the question came up in meeting today and I didn't have definitive answer. The U is considering a policy all IT purchased software be require to use Incommon / Shib and we were wondering if this policy would extend to in house developed applications.<br>
<br>
While I agree with Scott philosophically about CAS (api Client integration) vs Shib the unfortunate reality is that CAS is much easier for in house developer's to implement and results in less infrastructure/servers for my dept to maintain (ie many SPs).<br>
</blockquote><div><br></div><div>I'm curious why that would be? Over here SP care & feeding is the responsibility of the server-group and departments not IAM. If a dev wants to build a shib'd app on their desktop, that's cool too, just email us the SP metadata and about an hour later you're up & running.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another reality is that we are resource thin and asking the developers of these 100s of applications to move off CAS and onto Shib would take years.<br></blockquote><div><br></div><div>So why not do the CAS-Shib thing and make CAS the Auth system for Shib? You can then move off of CAS slowly and once you're ready to go 100% shib just replace the CAS part with shib's internal auth stuff.</div>
<div><br></div><div><br></div><div>Dave</div><div><br></div></div><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>