Ajcody-External-Authentication

  1. Zimbra Tech Center
  2. Zeta Alliance
  3. Ajcody-External-Authentication

External Authentication

   KB 2703        Last updated on 2016-06-20  




0.00
(0 votes)
24px ‎  - This is Zeta Alliance Certified Documentation. The content has been tested by the Community.


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.

http://www.zimbra.com/forums/

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.

Bugs/RFE's:

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-mapping>
   <filter-name>CAS Filter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

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:  

casclient/src/edu/yale/its/tp/cas/client/filter/CASFilter.java

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);
      return;
}

Support for SAML Shibboleth

Please see the following RFE:

References:


Support for SSO SPNEGO - ZWC, ZCO Outlook, And AD

Commonly Asked Questions That Need Answers
Existing References And Documentation

See the following [As of Apr 3, 2012]

Relevant Background Bugs/ RFE's
Comment #25 From David Pitt 2011-05-18 01:54:01
Approach adopted in current solution:

If you're signed onto a domain with a Windows username that matches the Zimbra
name used in the Outlook profile, then ZCO will attempt to use SSO, falling
back to a conventional signon if SSO fails.

This holds both for existing ZCO profiles and for new ones (so there's
currently no concept of a SSO-specific profile). In this respect ZCO largely
mirrors the SSO behaviour of the web client, always trying to use SSO first if
it's available. One key difference from the web client is that a ZCO user can
create a non-SSO profile for a different email account on the same server
(whereas if you point the web client at an SSO-configured server then you are
not given the opportunity to specify a username).

If the target server hasn't been set up with a SPNEGO redirect then SSO will
quickly fail (before any attempt to authenticate against the server) & fall
back to a normal signon. (So the impact on servers which aren't set up for SSO
is minimal.)

There's no new UI content at this stage for SSO. When creating a new profile
for an SSO target account the password can simply be left empty.

For correct operation ZCO must be configured with StorePassword=0 in the Zimbra
registry settings. (This can be set within the MSI using ZmCustomizeMsi.js
prior to installation.)

------- Comment #31 From David Pitt 2011-05-20 01:51:39

One extra bit of clarification on Comment #25:-  as with the web client, the
server name specified in the profile must match that used in the SPNEGO SPN (in
the Windows domain controller setup) for SSO to be used.
(See ZimbraServer/docs/spnego.txt for notes on configuring SPNEGO.)

So if, for example, the URL to be used with the web client in order to use SSO
is
   z32.puneqa.lab/zimbra/
then the ZCO profile will only use SSO if the server name is set to
   z32.puneqa.lab

------- Comment #32 From Nidhi Vyas 2011-05-20 02:23:05

Verified on ZimbraConnectorOLK_7.1.1.6321_x86/
7.1.1_GA_3183.RHEL4_64_20110516213106

Signed onto a domain with a Windows username that matches the Zimbra
name used in the Outlook profile then no need to specify the password while
creating profile.
Store password was set to 0.

Tried for both exsiting and new profile.
The target server had SPNEGO redirect enabled.

Marking this as verified.
Retrieved from "http://wiki.zimbra.com/index.php?title=Ajcody-External-Authentication&oldid=62202"
Jump to: navigation, search