[Deploying Sakai] AD, LDAP, and security
Jason Shao (CampusEAI Consortium)
jason_shao at campuseai.org
Tue Sep 22 12:33:02 PDT 2009
If you've very concerned about Sakai having access to usernames/passwords, some points:
* Sakai does not persist LDAP passwords, aside from the credentials it uses to bind to LDAP (in configuration), delegation of authentication as opposed to username/password synchronization approaches common in much software
* Sakai is open-source so you can see exactly what Sakai does with username/password credentials (as opposed to proprietary products which can be difficult to verify)
* One major reason for some SSO products like Jasig CAS is to protect user credentials (similar to the original Kerberos goals)
* Since your Sakai sits in the DMZ, your LDAP directory itself is still not exposed to the broader internet, protecting a defense-in-depth approach
In terms of security of the server - if someone can install an application on your server then they can basically compromise anything that server has access to, but that's true for most any (my main focuse would be to make sure you've locked down Tomcat (esp. default passwords for the manager webapp - OWASP has a good guide: http://www.owasp.org/index.php/Securing_tomcat) and default services. platform/application.
* Note: many people miss the tomcat manager bit since it doesn't show up in webapps (in TC 5.5 anyway)
If it makes them feel better it may be worth getting a 3rd party audit done of your service to demonstrate you've done your due diligence. CampusEAI for instance works with an external firm as part of our overall product/service cycle, and it's a useful external check.
Director of Product Development
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
From: production-bounces at collab.sakaiproject.org [mailto:production-bounces at collab.sakaiproject.org] On Behalf Of Paul Gibbs
Sent: Tuesday, September 22, 2009 9:11 AM
To: production at collab.sakaiproject.org
Subject: [Deploying Sakai] AD, LDAP, and security
Faithful to their jobs, our network admin is uncomfortable with the idea of opening up Active Directory to Sakai via LDAPS. Does anyone here have any thoughts on the risks of using LDAP/SSL with Sakai? I know many of you are running AD/LDAPS in your environments and are doing so securely. Obviously this is more about threat reduction vs. threat elimination, but what steps should we take to provide as secure an environment as possible?
Currently, I am running Sakai behind Apache mod_proxy (on the same server), which is itself behind a commercial firewall (on the network). Apache encrypts all traffic via SSL. Sakai sits in our DMZ and currently has no access to network services. If we move forward, all LDAP communication would definitely be encrypted via SSL, and only port 636 on the LDAP server would be exposed to Sakai.
>From my perspective, I guess the concern isn't so much about packet sniffing, since the entire path is locked down via SSL. The concern lies more in Sakai itself and what safeguards are built into Sakai to keep someone from installing an application on the server itself which would watch the username/password activity. We are running Debian 5 and 2.6.x.
Maybe this is a matter more about how Java handles security than it is about Linux?
Insert movie times and more without leaving Hotmail(r). See how.<http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009>
Your input is important to improve upon our continuous efforts to service you better. Please e-mail my manager at anjli_jain at campuseai.org with any feedback.
This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of CampusEAI Consortium or the Open Student Television Network. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. Warning: Although precautions have been taken to make sure no viruses are present in this e-mail, the companies cannot accept responsibility for any loss or damage that arise from the use of this e-mail or attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the production