Jeremy Smith's blog

Entry Is Labelled

Using "Google Apps for Education" at Case Western

I may be about to shock you. You see, if you know me, you would think that Google Apps for Education is something I would be all about. I would be wearing a T-shirt reading, carrying a sign saying, and chanting "We Should be Using Google Apps for Education."

I'm not. And I don't think we should.

I'll try to explain.

There are several ways this could be done. One way is to convert all the Case accounts to Google accounts. Another way is to just convert a section of accounts to Google accounts (like "students," for example). Yet another way is to have everyone maintain two accounts.

All Accounts are GoogleCase Accounts

[Note: I'm going to be abbreviating Google/Case accounts from here on out as "GCase accounts."]

Let's say that we are going to do all of the accounts. We hook our Directory Service up to their user account API (hinted, but not documented anywhere, at http://www.google.com/support/a/bin/answer.py?answer=46594). Your GCase account would look just like your Case account now. It would be something like "jeremy.smith@case.edu" (or "jms18@case.edu"). To check your email, you would get POP access at pop.gmail.com (you would be logging in with your GCase credentials i.e. "jeremy.smith@case.edu" not your gmail credentials, "jeremy.smith@gmail.com"); or you would use their webmail which would end up being hosted at http://mail.google.com/c/case.edu. (No IMAP with GCase , but that's forgiveable) So, there are no "Case accounts" in this scenario (no Kerberos), there are only persons' "GCase accounts."

To protect other web resources (such as checking grades, logging into the HCM system, etc.), we would need to integrate with Google's SSO system. Which they have an API for — Account Authentication Proxy for Web-Based Applications (it works almost exactly like CAS).

What doesn't work in this situation: security. ITS is no longer in control of the accounts. We can't implement password policies. We don't have access to audit trails and logs. People are using these GCase accounts to retrieve paychecks, to receive grant money, to check their grades, get transcripts, register for classes, to log in to protected document areas, etc. and there is no way we can effectively and accurately determine where and how. It's the kind of stuff that keeps auditors, lawyers, and CISOs awake at night. Not to mention that we've effectively tied ourself to a single vendor — if this were Microsoft (Hailstorm, anybody?) or Oracle, nobody would be making posts welcoming its reception.

There are stopgaps that could be put into place to alleviate the security concerns. We could maintain a separate authentication mechanism that ITS would require be used in cases of sensitive information. That is, when you login to get your email, use your GCase account; when you login to check your grades, use your über-secure ITS-provided account. But that's basically converging towards the next two methods of integrating with GAfE:

Students have GCase Accounts / Staff have Case Accounts

[Saying "students have GCase and staff haven't" is just arbitrary. This is basically "genre X of people have GCase and genre Y don't."]

This eliminates some of the security concerns but many remain present. ITS doesn't get the added bonus of shutting down all of our mail servers as they will be needed to handle mail for those that have regular Case accounts and to route the mail for GCase users over to GMail.

We could make this all happen upfront. When you activate your account, if you are a student, the web page uses Google's API to activate your GCase account; otherwise, a regular account is activated. Then behind the scenes, we handle all the mail routing issues and such to make sure mail goes where it needs to go.

So that would all work.

But what about authentication to web resources? To authenticate students, one would have to leverage Google's Authn API. To authenticate everybody else, you have something different.

It's a hodgepodge on a massive scale. And it alleviates less than half of the security concerns mentioned with the all-or-nothing-GCase-accounts. And it introduces a host of non-obvious problems, like people becoming immensely confused as to how to reset their passwords.

Everybody has Two Accounts: a GCase Account and a Case Account

Following along the spectrum of possibilities from all-GCase-accounts to some-GCase-accounts-and-some-Case-accounts, you eventually reach the other end which is that everybody maintains two accounts.

Each user then decides which email service they want to use. If you use GCase mail, use your GCase credentials. When accessing Case web resources, use your Case credentials.

This is what we already have.

Anybody can forward off their mail go GMail. And through GMail, they can send on behalf of their Case email address, "jeremy.smith@case.edu".

There are ways we can streamline. When a person activates their account, we can upfront offer to send their email off to GMail (and we could even include Yahoo!, Hotmail, etc. in the list of places to automatically forward off your mail to).

So... yeah... we already have this one. We've had it since before GMail was on the scene.

The Fix

There is a clean solution to this. And it's quite simple.

Google agrees to integrate with our login system — http://login.case.edu. It works almost identically as theirs. That's all that needs to be done.

You go to http://mail.google.com/c/case.edu, you get redirected to http://login.case.edu, we handle your credentials, and upon successful authentication, we send you back to http://mail.google.com/c/case.edu with a token that says you correctly authenticated with us. We point our MX records to them. All @case.edu mail flows to them, and we maintain control of our @case.edu accounts.




*whew*, okay that was a lot of rambling. I'm going to stop now before I go into any Federated Identity stuff. Go ahead and take it into the comments. There might be a solution I haven't thought of yet.

Comments

  1. gravatar

    Give them a little time. The Education service has only been publicized, since, what, Monday? They do claim to be listening to concerns, so CAS/LDAP integration could happen.

    The only other (fairly ugly) mechanism I can think of for "unifying" the signons is to update the GCase password (if the XML-RPC API allows that) when we modify a kerberos principal. We'd have to undergo another round of "everybody change your password", and there wouldn't be anything to stop users from getting them out of sync again(changing via Google's stuff, running kpasswd, etc.)

  2. gravatar

    If they'd implement integration with common SSO solutions or leveraged some kind of Federated Identity protocol, I'd be all about it. I'd be the first one to sign up to change the MX records.

  3. gravatar

    I know this maybe old news, but looks like in October they came out with a SSO system using SAML 2.0 as well as other API features.

    https://www.google.com/a/help/intl/en/edu/administration.html

Post a comment