Main Nav

Message from dperrin@keene.edu

Hello,

 

I'm working on institutional identity management efforts and a goal to reduce login combinations. I'm very interested in understanding best practices to follow in pursuit of reducing login combinations. Most of our internal applications and externally hosted web applications use application specific authentication sources. Our team will soon be configuring select internal applications for LDAPS authentication.

 

Here's where things get interesting... at least one of our internal applications supports LDAP (not LDAPS). All of our web application vendors support LDAPS but not all of them support token based authentication (like CAS or Shibboleth). I've found little information about when LDAPS authentication with hosted apps would be acceptable - or if it should be avoided at all costs. There is very high trust and confidence in our hosted web app vendors but I have some reservations about passing user credentials over HTTPS through a third party and then back to us via LDAPS.

 

Any pointers, thoughts, or suggestions on criteria for selecting appropriate authentication mechanisms would be greatly appreciated. Pithy one liners would be great to hear too.

 

e.g., "Never do LDAP:389 authentication even internally and even with all the networking tricks you can think of." - or - "We use LDAPS for a few hosted web app vendors, CAS and CAS-Shib where we can, and LDAP and LDAPS for internal apps."

 

 

Best regards,

 

David Perrin

Enterprise Application Developer

Keene State College

 

 

 

Comments

Never do LDAP:389 authentication even internally and even with all the networking tricks you can think of.

 

I would also avoid doing LDAPS with third parties where the user password passes out of your control and through a third party application.  If you do, I would try to get some wording in your contract with them about not storing, caching, logging, or general misuse of your passwords.

 

In general, always use LDAPS and if it is a Web application make sure it is using HTTPS.

 

SASL authN over 389 should be okay. 

/mrg

On Jan 25, 2012, at 11:25, Jones, Mark B wrote:

Never do LDAP:389 authentication even internally and even with all the networking tricks you can think of.

I’m not familiar with SASL.  Does that encrypt the password before transport?

 

SASL authn over LDAP exposes itself to replay attacks. For example, see http://users.tkk.fi/u/autikkan/kerberos/AIWSC03_kerberos_replay_attacks.pdf. Depending on the authentication mechanism, you can often mitigate this, e.g. by reducing the time skew allowed between client and server, but it is a known risk/vulnerability.

 

My colleague RL "Bob" often says: "It's all risk management." So whether you should or shouldn't depends on your risk acceptance/aversity. :)

 

 

I would agree with Mark Jones – it doesn’t matter how secure the transport mechanism is, if your passwords are being transmitted to an external entity you have essentially lost control over them.  I would go further than Mark and say regardless of the wording in your contract about not storing, caching, or logging, the only safe bet is to not to send the vendor your passwords in the first place.  The people the vendor has working on the contracts are not the ones who implement their systems; they probably don’t even talk with each other very much.  Even if you get an ironclad promise into the contract the vendor will not do any of these things, they very well may now or sometime in the future.   Moreover any remedy you may get for a breach on this point when it all goes awry is not likely to yield anything near the heartache it will cost you.  The vendor will probably say they are sorry, they didn’t realize it was caching passwords, or that they were only doing it to troubleshoot a problem, or some other reason they will invent after the fact.   Bottom line - if the vendor can’t work with a zero knowledge authentication scheme, then either don’t use them or force a separate username/password.

 

Pithy one-liner to vendor:  “If your authentication isn’t zero knowledge, your developers probably are.

 

Loren

 

 

> I'm not familiar with SASL. Does that encrypt the password before > transport? SASL is just the framework, some mechanisms do, some don't. -- Scott
With LDAP authentication the user has to hand their password to the vendor. In addition to losing control of the password, having multiple sites that users login to, especially external ones, may reduce their awareness of phishing attacks. We do have some internal applications that use LDAPS but we convert them as we can to Shibboleth.

Regards,

Brendan Bellina
Mgr, IdM
University of Southern California

On Wed, 25 Jan 2012, Brian Arkills wrote: > My colleague RL "Bob" often says: "It's all risk management." So whether > you should or shouldn't depends on your risk acceptance/aversity. :) Well, I'm nothing if not predictable. As I was reading David's post I was muttering to myself: it's all risk management. And as our fellow cubemate Michael said this morning when we were chatting about it, that's easy to say, but harder to put into practice (ie, doing good risk management). I usually think of it as "taking the risk management perspective". What does that mean? In this context it means that in running an authentication service for an institution you will be obliged, sometimes, to support bad (risky) practices. You will lose some, perhaps many, battles. So you focus on doing the best you can, with the resources you have, where the risks are highest. You tend not to ask "is practice X OK?" rather: "what are the risks of using practice X in this situation, versus the effort required to do something less risky?" Assessing risk and effort is not easy. That's why it's good to have a list like this one where we can share experiences. Even better is the work to record some of this experience here: https://spaces.internet2.edu/display/iamtep/IAM+Tools+and+Effective+Prac... I would encourage those (including me) who spend time offering their opinions on this list to contribute to that work. (And this is part of the reason I'm enthusiastic about the OSIdM4HE work, so we can put more of our good experience into practice.) To get back to David's original question: when is LDAP/LDAPS authentication OK, especially with external/cloud apps? As others have implied, the better question is: what risks are there in using those schemes, in those situations, and how can I (as a responsible architect/manager, who values his/her job) best control them? One part of that is: if you don't have a solid alternative to offer (to a risky practice like LDAP-in-the-clear), then you can't put up much of a fight. At UW we've made a big investment in the redirect-webSSO method for almost 15 years now (pubcookie, now increasingly SAML/Shib) and in my view that has really helped manage password-exposure risks. Does LDAP authentication still happen in some cases? Yes, but far less than it would otherwise. Part of the success of the program is getting users and business people to assume that webSSO integration is the norm. So when the biz people are negotiating with the vendor they'll insist on it (often, not always) which is a much stronger position than if the IdM guy comes in late saying "I don't like this". Another part of the risk management calculation is: how many users and who are they? If an outsourced app is used by 1% of your staff, then it's a lot lower risk. Fighting hard not to use LDAP(s) may not be worth it. But if those staff are key admins with a lot of power, maybe the risk is higher. This is why two-factor authentication programs, even if small compared to the overall user base, can be very important. If you can protect your key internal biz systems with two-factor authn you can probably spend a lot less time worrying about password exposure in less-risky outsourced systems. Of course if your key biz systems are being outsourced ... then you fall back to (as Mark suggested) getting stuff in contracts that pushes the risk to the vendor, even knowing (as Loren says) that that may not make a practical difference. (But here I'd still ask: do we have any evidence of password exposure at vendors actually causing problems?) At some point the risk calculation becomes "risk to your job"; if you have raised the right issues, at least when the disaster happens you can say "I told you so", or, better, "this is why we need to put more investment into my team so we can control this risk better in the future and save the institution from cost and embarrassment". I could start in on the importance of getting institutional policies in place too, so it isn't just the IdM manager's opinion on things ... but I'll stop here. - RL "Bob" Morgan UW-IT IAM
Will decisions such as these effect InCommon Silver qualification?
I of course meant 'affect'.
Protected Channels for inscope applications seems to be the norm, although one could argue 4.2.3.5#2 should have a must instead of a should. Non-IdP applications _must_ have policies and procedures on usage for scenarios like this to minimize risk. Getting rid of clear text transmission of LDAP is a great one.
Message from dperrin@keene.edu

Thank you all for your thoughtful replies! This was very useful.
Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.