Editor’s note: Federated identity management simplifies the inherent identity management issues of using cloud-based...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
unified communications, hosted collaboration tools and SaaS office.
When we go into work, we typically log in once to Windows to access email, unified communications (UC) and corporate applications. To make this happen, there is a fair amount going on behind the scenes to give the user one sign-on, or single sign-on (SSO), to multiple applications. But when we want to log in to our Microsoft Office 365 or Google Apps online accounts, we’re presented with a new ID and password request. This is not good. Managing multiple IDs and passwords is not only problematic for the user, but it also puts the corporation at significant risk.
When users are forced to work with multiple IDs and passwords, they are naturally inclined to simplify and reuse the same ID and/or password on multiple systems, which turns online services—like Windows and Google Apps—into an open door for hackers to obtain an ID/password combination that also works on the corporate network. This has already happened in a highly publicized Twitter attack where a Twitter employee used the same password for their corporate and private Google Apps accounts.
To address this issue we need a federated identity management strategy to extend single sign-on into the cloud for unified communications and Software as a Service (SaaS) office. Identity federation enables users to log in once to the desktop using good ID/password practice and gain automatic access to online accounts.
Federated identity management with SAML
Identity federation includes the passing of authentication and authorization information to achieve SSO. There are primarily two open standards to achieve this: Security Assertion Markup Language (SAML) and OpenID. Most online UC and SaaS office services typically support both SAML and OpenID, so to illustrate we’ll just focus on SAML.
SAML is an XML-based open standard from the Organization for the Advancement of Structured Information Standards (OASIS) for exchanging authentication and authorization information. SAML increases security by reducing the number of times a user needs to log in to an application, particularly over the Internet. SAML also increases application access by streamlining the log-in process, and reduces help desk and administration demands.
The way SAML works is pretty straightforward. The identity provider (IdP)—the organization-maintaining directory where the user has an account, such as Active Directory—talks to the service provider (SP) or UC or SaaS office application. When the user attempts to access the cloud application, say Google Apps or Microsoft Office 365, the connection is intercepted and routed to the IdP. Federated identity software running at the IdP authenticates the user. The IdP then sends a token to the SP after the SP validates the IdP. The user is finally redirected to the SP’s application. All this goes on in the background and occurs fast enough that users typically don’t notice the process.
To further illustrate the notion of federated identity management, let’s look at an example using Microsoft Office 365. The users sign in to their desktop with their corporate ID and password. They are authenticated on-premises as part of the log-in process. The users then attempt to access the cloud service via their Web browser. For Office 365, IT administrators must set up the Active Directory Federation Servicer 2.0 (ADFS), or IdP, in addition to Active Directory (AD). The ADFS talks to the Microsoft online services federation gateway, or service provider. The federation gateway takes care of SSO with cloud applications, such as Office 365. But to make this work there must be a trust relationship between the company and the cloud service. Establishing this relationship requires registering the enterprise domain using an SSL certificate from companies such as Entrust, Go Daddy or Symantec (VeriSign).
Sound complex? Well, it’s not rocket science, but it does require planning, training and staging. There is an open source alternative called Shibboleth. Shibboleth provides open source code for both the IdP and the service provider.
When looking to extend unified communications and SaaS office to the cloud, federated identity management must be a priority to make life easier for employees and to better protect the company’s interests.
About the author: Ted Ritter is a senior research analyst with Nemertes Research, where he conducts research, advises clients and delivers strategic seminars. A Certified Information Systems Security Professional (CISSP), Mr. Ritter leads Nemertes' research on information stewardship, which includes compliance and the management, access, storage and backup of data.
Mr. Ritter has designed, implemented and supported telecom and information security solutions for commercial, federal and international clients. He holds a master's degree in telecommunications management from George Washington University and a bachelor's degree in neuroscience from Oberlin College.