Windows IT Pro has a new columm by Sean Deuby named "Enterprise Identity" that is quite useful. His column, "Federation Paves the Way Toward True Enterprise Cloud Identity" in the February 2011 issue is full of information relevant to those of use making decision when it comes to what goes up in the cloud. Below is a primer when it comes to Identity -

Identification - who are you?

Authentication - I need to verify that you are who you say you are.

Authorization - these are the things you can do because of who you are.

Auditing - we are watching what you are doing.

I found Sean's column full of great information. Here are some of the best tid-bits (some direct quotes, some I've put my own spin on) -

• Cloud computing complicates the traditional, password-based model because cloud services aren't on your protected corporate network. This is a good piece of information to keep in mind, even for technical folks.
• Enterprise cloud identity (which might seem like an oxymoron but makes sense more & more every day) is the practice of securely extending the core corporate identity infrastructure outside an organization's perimeter to manage access to distributed services, applications, and infrastructure.
• Trying to push passwords into the cloud is like putting the bank vault door on the outside of the bank. Even using something like the Google connector for Active Directory pushes your AD password out to Google - not a good idea even if their motto is, "Don't be evil."
• Securely extending your existing corporate identity infrastructure outside your organization's perimeter, without entering another password once you've logged on to your corporate network (aka Internet single sign-on or SSO) requires another method - federation.
• Federation (federated identity) - is a collection of standards and technologies that enables authentication & authorization data to securely pass between an identity provider (Active Directory on your local domain) and a service provider (such as a cloud-based CRM) without exposing password data.
• Federation uses security tokens in much the same way that Kerberos uses tickets. Kerberos tickets and federated security tokens are tightly restricted on when they're valid - they are not usable out of the context they were generated for. The best part is that these tickets & tokens contain no password data.

Microsoft's Active Directory Federation Services (AD FS) looks interesting for those of use running Windows networks. But what is most interesting is Google and how they handle Identity across their various platforms. I can sign into Gmail then bring up another tab and be signed into Blogger, have another tab with my Google Docs, and the last tab will have Android Marketplace. Google might be a good initial model when thinking about Federated Identity. Of course that's just my opinion, I could be wrong (thank you Dennis Miller).

Rob