Difference between revisions of "Ajcody-External-Authentication"

m (CAS and Public Share Issues)
m (JA-SIG Central Authentication Service Or CAS)
Line 44: Line 44:
*CASifying Zimbra How-To
*CASifying Zimbra How-To
** http://www.ja-sig.org/wiki/display/CAS/CASifying+Zimbra
** [[Cassifying_Zimbra_5]]
*** For ZCS 4 & 5 see also:
**** http://www.ja-sig.org/wiki/display/CAS/CASifying+Zimbra+4.5+and+5.0
** [[CASifying_Zimbra_6.0]]
*** See also: http://www.ja-sig.org/wiki/display/CAS/CASifying+Zimbra+6.0

Revision as of 16:53, 29 December 2009

Attention.png - This article is NOT official Zimbra documentation. It is a user contribution and may include unsupported customizations, references, suggestions, or information.

External Authentication

Actual External Authentication Homepage

Please see Ajcody-External-Authentication

General Topics

Zimbra supports the ability to use an external authentication source, but we don't support the external authentication servers setup and configuration.

Please see the following for more details:

You can also use the forums to see if others have worked out some good instructions when working with your particular external authentication server.


Another possibility is the use of Preauth, see:

SSO with Sun IAM - Identity And Access Manager

There is no Access Manager Policy Agent for Jetty Application Server [Oct 21, 2008]. We suggest the following.

  1. Build a webpage that is protected by Sun Java Access Manager. Presumably this would be an apache tomcat served page so that SJAM would be able to manage it with its existing policy agent for apache tomcat. This page would interact with SJAM to get access checks and then use the standard Zimbra pre-auth mechanism to pre-auth the user and bounce them into the zimbra app.
  2. In Zimbra, you would configure (on the domain) zimbraWebClientLoginURL (and zimbraWebClientLogoutURL), to the address of that apache tomcat served webpage from step 1 above. If someone attempts to login to zimbra directly, they would be redirected to the page which is controlled by SJAM. And when logging out, they would be again redirected to the webpage that is controlled by SJAM. There would be no way to log into or out of Zimbra without the approval and control of SJAM.

For details on the preauth mechanism, see:

JA-SIG Central Authentication Service Or CAS

CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a JA-SIG project in December 2004.


CAS and Public Share Issues

Adding the following as reported by a customer, with their permission.

When a Zimbra calendar has a Public share added, the url is something like 
"https://my.server.edu/home/user@domain.edu/Calendar.html".  Once the Zimbra 
app determines that this calendar has a Public share, it gets the calendar 
data through the /home directory path, but it requests the images and css data 
from the /zimbra/img and /zimbra/css directories.  We previously did not let 
unauthenticated users access /zimbra/img or /zimbra/css.  We added a modification 
to our casclient.jar code to allow requests from non-authenticated users to 
return data from these two directories, since these two directories do not 
contain any user or private system data.

And a more detailed explanation:

In the CASifying Zimbra setup, this is the default filter mapping they have you 
set up in the /opt/zimbra/jetty/etc/zimbra.web.xml.in file:

   <filter-name>CAS Filter</filter-name>

This default url pattern will trigger Zimbra to run any request made to 
"https://my.server.edu/zimbra/..." through the casclient.jar filter.

Note, one thought my co-worker and I had was to modify this section of the 
zimbra.web.xml.in file to exclude /img and /css, which should accomplish the 
same thing we did by modifying the casclient.jar file.  Unfortunately, in our 
web-searching for Jetty Servlet 2.4 information about what you can do with the 
url-pattern, it did not appear that you could exclude or negate any url-patterns.  
If you or some other individual had any desire, you might have more luck in 
finding a way to accomplish this.  We thought it was better to modify the 
casclient.jar file anyway, as that carries over through upgrades, but changes to 
the zimbra.web.xml.in file have to be reapplied after every upgrade. **

Any custom filtering you wish to do for your location would be made in the 
casclient.jar archive.  After unjarring casclient.jar, the file you will modify is:  


Certain requests could be filtered out before being sent on to the CAS server 
to reduce traffic and cpu usage.  Some examples would be requests for the login 
or logout pages, as the user is on their way to authenticate or de-authenticate, 
so checking these requests would usually be unnecessary.  This is also the place 
where we added code that excluded the /zimbra/img and /zimbra/css directories.  
Your code would look something like:

String uri = ((HttpServletRequest)request).getRequestURI();

if(uri.startsWith("/zimbra/img") || uri.startsWith("/zimbra/css"))
      fc.doFilter(request, response);
Jump to: navigation, search