It appears that you’ve simply reimplemented Zimbra authentication in terms of SAML 2 protocols – that’s “SAML 2 protocols”, mind you, not even “SAML 2 bindings”. This is all well and good, but it’s not the way people want to use SAML 2. They’re interested in using the SAML 2 “Web Browser SSO Profile” (See section 4.1 of the saml-profile document) to SSO into Zimbra from their corporate portal. I’ve looked at your example code – you at least need an assertion consumer service, and then you need to cache security context locally, rather than go ask the SAML authority every time someone hits the zimbra server. I’d recommend incorporating something like spring security 3 saml extensions into the zimbra server to handle building a saml-based security context on the servlet request. Then your SAML security provider could simply use the credentials on the request context to build a zimbra auth token for the request.

John Calcote
Sr. Software Engineer
Novell, Inc.

I am not an expert on shibboleth, but from what I know, to shibboleth-enable an application a shibboleth daemon and a web server module need to be installed on the application side. The daemon talks to the shibboleth IdP, and the web server module acts as an interface between the daemon and the application by passing along user attributes obtained from the SAML assertion (issued by the IdP) or possibly the complete SAML assertion itself. A typical Zimbra install does not include a web server, so one would have to first put (say) an apache proxy in front of Zimbra and then install the shibboleth SP component there and configure it to pass along the SAML assertion obtained from the shibboleth IdP. After that the idea of implementing the SamlAuthProvider Zimbra server-extension would come into the picture to validate/process the assertion.