Please, somebody talk me down!

[Jim Fox]

David,

Go to sleep.  It'll be better in the morning.

Jim


On Sat, 2011-07-30 at 10:42 -0800, David Bantz wrote:
> I have this nightmare with four scary things going on:
> 
> A vendor with an application newly licensed by my institution for use by students, faculty and administrators says they can use our institution's central authentication and yes, they can use SAML to authenticate with our Shibboleth IdP.  I'm liking this part and move on to the attributes the service needs, reminding them that with SAML/Shibb I can pass them current values of  attributes upon successful authentication.  "Well, no, we don't consume attributes; we require a batch text file with tab-delimited values of these attributes for all users" and they show me a list that includes name, dob, SS#, contact information, gender, ethnicity, as well as details of the student record.  
> 
> My ERP is deploying a tool to provision identity information to my IdM in real time; moreover the ERP's own authentication now integrates with CAS.  We've spun up CASSHIB to bridge CAS and SAML protocols in a single SSO session, so I'm very excited that users of the ERP web interface will participate in our SSO environment.  "Well, we require several extensions to CAS, provided in jar files specific to the JASIG implementation."  So it looks like the ERP may remain a non-participating island "SSO."
> 
> A third vendor service which has been integrated via InCommon and does consume attributes for entitlements turns out to have less than good practices and support on their end, and turns off their SP unannounced.  In follow-up conversations they indicate there is no actual plan or target date to upgrade the SP, and it certainly won't be upgraded for a couple of months.  "But it's not such a big deal, we have an alternative in-house authentication system." It turns out this is a credential relay: users hand over their credentials and if the service can successfully spoof them, they know they have valid credentials.  Remember, they turned off the SP because they couldn't maintain or support it properly.
> 
> For the umpteenth time, senior IT managers advise me that if we simply used "AD authentication" all services would automatically be integrated securely, reliably, with minimal maintenance or support.  Neither the vendor's proprietary interfaces and extensions of open standards nor today's two-hour unscheduled outage of the entire Domain are reason for concern.
> 
> You may have guessed that these aren't nightmares in my sleep.  These are only slightly disguised and compressed versions of actual events - and they all happened this week.
> 
> But that's still not the most scary thing to me.  I know that many of the people on this list use the same external services in my nightmare and/or the same ERP and/or have executives who also think one or another favorite vended technology is an elixir that effortlessly provides a complete solution to IAM.  And I don't see us as a community objecting or otherwise acting effectively to steer us toward more secure and sustainable practices.
> 
> About two years ago InCommon seemed on the verge of stasis.  Concerted efforts to get more members, provide additional services, advocate the federation to senior executives, and put it on sounder financial footing were, I think, effective in reviving InCommon's role.  I'm concerned the four scenarios above - if they are at all representative of our experience generally - indicate at least as serious a crisis for SAML/Shibboleth and more generally for secure privacy-preserving authentication and authorization.  And, as I say, I'm seeing acquiescence in those practices which threaten to derail the move to secure standards-based trusted third party authentication and SSO.
> 
> Can somebody talk me down?  Wake me from my nightmares?  Start a movement?
> 
> David Bantz
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net