Home › Blogs › EMU_Mike's blog

Zimbra implementation

Mon, 2008-06-16 11:35 — EMU_Mike
0
No votes yet

EMU is implementing commercial Zimbra, and I see this as a good excuse to get active on lumdev finally.

Issues we will have to contend with:
SSO to Luminis
Account provisioning
Calendar provisioning and events
collaboration suite data
account deletion process

Since Zimbra has multiple levels of account license, controlling who gets what type of account will matter a great deal, as we only have so many of the higher level licenses to dole out (for faculty and staff) while everyone else (students) will get the lower license level.

SSO looks fairly simple using the preauth functionality that Zimbra has.

We can probably write a Zimlet to do mail or cal preview.

I need to look into the Zimbra collaboration more to see if it can replace group studio.

Account provisioning looks like it will be handled with our IDM EAS ldap.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mon, 2008-06-23 04:55 — shiva

my 2 cents in this case

Helo Mike,
We at USD didn't implement Zimbra. i know Plymouth State University has implemented Zimbra and integrated it with their Lp IV version. Please contact PSU it personnel - may be they can give you more detls.

Thank you,
Shiva

Thu, 2008-06-26 12:57 — saki

Zimlet

Mike,

I'm interested in building email and calendar preview channels. What do yo mean by a Zimlet? Is a Zimlet built with CAS or the preauth functionality with Zimbra? Where can I find more information/documentation on Zimlets? Do you have any sample code to share?

Thanks,
shyam

Mon, 2008-06-30 10:19 — EMU_Mike

After doing a little

After doing a little research I'm not really sure how we will use Zimlets. We still have to figure out how to write the preview channel. Worst case is that we will harvest the login credentials and then write an imap channel to pull information down.

More Zimlet info:
http://wiki.zimbra.com/index.php?title=Zimlets

Fri, 2008-07-18 15:45 — EMU_Mike

Pilot users on Zimbra

We are taking a different approach to piloting this until production hardware can be purchased and installed. We have set up Zimbra on a local server (production will be hosted by our ISP, Merit) and pilot users are using local Zimbra to access their existing SunONE mail through IMAP. We're basically piloting Zimbra as only the front end before migrating mail. To deliver, we created a custom role called zpilot and use the dlm to show a tab delivering Zimbra only to users with that role. Easy enough.

The session management has been an interesting trip. Teammate Ann Marie wrote a hook into the Luminis login front end so we can store username and password (encrypted of course) and then pass it on Zimbra's preauth url when the user clicks on the E-Mail tab. The preauth function write a cookie called ZM_AUTH_TOKEN to show authentication. The part we're struggling with is how to manage the Luminis session and the Zimbra session together. Logging out of Luminis does not remove the Zimbra cookie, so if the user is using tab-delivered Zimbra then logs out of Luminis and walks away from a public computer with the browser open anyone could walk up, access the web front end of the Zimbra server from that same browser window and have full access to that person's email. Likewise, if we delete the ZM_AUTH_TOKEN cookie on Luminis logout then someone is using Zimbra from the native web interface and logs in/out of Luminis would immediately lose their Zimbra session as well. That is, assuming we can configure Zimbra to use a different cookie domain than the very specific one it uses now, which can't be affected by the Luminis server.

Decisions for the whole group, I suppose.

Thu, 2008-07-24 10:06 — EMU_Mike

Expired Accounts and Logged In Sessions

Two interesting issues about the implementation....

We hijacked the regular Luminis login process to nab and encrypt username/password for creation of the Zimbra preath URL, and have used that "hook" now for two very useful things.
1. Redirection on expired password: Since we're binding to the ldap before passing the credentials on to Luminis, we can read the account expiration flags and see if the password has expired in IDM. If it is we just redirect to our password management screens for a change rather than pass on to Luminis.
2. "Forward-Only" account option. Part of the "email for life" plan we are implementing involves transitioning alumni and retirees to an account that only has forward option (no local mail store for these account.) By hijacking login and reading the forward-only flag in IDM we can redirect the user to the forward management screens instead of to Luminis, where they would have no login privilege.
These are great because they keep people going to the URL they (hopefully!) are familiar with.

The other big question here is "how are we going to deliver Zimbra?" In a tab? As a pop-up? Either way, we need to call the preath url to generate Zimbra's auth cookie. The problem here is that logging out of Luminis will not log one out of Zimbra. Scenario: user logs into portal, access Zimbra on a tab, then logs out of Luminis but leaves browser open. Next user gets to machine and browses to mail interface directly (not through Luminis.) Since the cookie is still there they would immediately get the other person's mail.
I know what you're thinking... "so delete the Zimbra cookie on Luminis logout!" That has it's own challenges. Imagine scenario 2: A user is in the direct mail interface composing the mother of all emails. They open another brower window/tab to access Luminis to get some information from Self Service, then log out of Luminis. When they return to Zimbra, they are surprised to find themselves logged out! Or probably more likely, a user has both interfaces open and Luminis times out and logs off. Bang. No more Zimbra.

I've run the issue by our instructional techs. They are so good at understanding our user community and I'm hoping they can give me some idea as to which approach to take.