It’s probably not worth the trouble.
We all get Authentication — Are you who you say you are? — and we all get Authorization — Are you allowed to access this resource? We layer in time constraints, location constraints, notions of groups & roles, and so forth, to specify Policy. Now here’s an important implementation question: What should specify your Policy, your identity management system or your applications?
That depends on a few things, including what you mean by that word ‘your.’
Common sense says that I decide who has accounts for what services in my company, I set the password complexity and reuse policies, I decide if there’s a 2FA requirement for this or that, I decide how long a user session can be before idling out, and I decide how long my applications can go on their merry way before checking in to make sure the user’s access hasn’t been cancelled. So many “I“s… very egocentric, no? Well, no — It’s my frickin’ company! I have security concerns and compliance constraints. Of course I set the policy!
Enter systems engineering: We ensure that the the identity management system is available to the application, we ensure that the application has access to the information it needs, and we require the application to enforce our policies.
So, Google for Business… Google requires that we create an account for our users there first, after which SSO with our own IdP is allowed. That’s not a problem; I’m sure that helps with their licensing and billing. After that, though, things go awry quickly.
- Google gives strong caution to our users that the company, not Google, is managing their accounts, and that we may have access to the data in their accounts.
- Logging into Google administrative areas explicitly requires the use of credentials on Google rather than requiring us to specify an admin role in our SAML transmission — that’s a Google policy.
- Google will occasionally demand from a user that he re-authenticate using Google credentials, bypassing or ignoring the corporate authentication system.
- Once logged in with the corporate system, Google will keep the user logged in to the Google services, ignoring corporate session policy set on the corporate system.
Those are serious indicators and concerns in my book. We should not have a service we pay for in conflict with our own policies and central management systems. At a minimum, it forces the corporate administrators to maintain users, credentials, and logs, in two different locations.
Now if you’d like Google to be your company’s identity management provider — with your users logging into all of your apps with your Google credentials — well, that’s another story! It seems Google is happy to help there for $5/month per head or so.
As it stands today, I personally use my own IdP service to SSO login to a few legacy Google for Business domains as a convenience, putting up with the quirks, but I would be hesitant about recommending that as a seamless solution with smooth user experience to corporate clients. Google simply violates too much of what we expect from centralized corporate identity management. Be careful before locking in with them.
Feel free to contact us with questions, comments, or your own experiences, or when you’re considering your own identity management architecture.
