By Patrick Harding
The Problem with Passwords
The average enterprise employee uses 12 userid/password pairs for accessing the many applications required to perform his or her job (Osterman Research 2009). It is unreasonable to expect anyone to create, regularly change (also a prudent security practice) and memorize a dozen passwords, but is considered today to be a common practice. Users are forced to take short-cuts, such as using the same userid and password for all applications, or writing down their many strong passwords on Post-It notes or, even worse, in a file on their desktop or smartphone.
Even if most users could memorize several strong passwords, there remains risk to the enterprise when passwords are used to access cloud services (such as Google Apps or Salesforce.com) where they can be phished, intercepted or otherwise stolen.
The underlying problem with passwords is that they work well only in “small” spaces; that is, in environments that have other means to mitigate risk. Consider as an analogy the bank vault. Its combination is the equivalent of a strong password, and is capable of adequately protecting the vault’s contents if, and only if, there are other layers of security at the bank.
Such other layers of security also exist within the enterprise in the form of locked doors, receptionists, ID badges, security guards, video surveillance, etc. These layers of security explain why losing a laptop PC in a public place can be a real problem (and why vaults are never located outside of banks!).
Ideally, these same layers of internal security could also be put to use securing access to cloud services. Also ideally, users could then be asked to remember only one strong password (like the bank vault combination), or use just one method of multi-factor authentication. And, ideally, the IT department could administer user access controls for cloud services centrally via a common directory (and no longer be burdened by constant calls to the Help Desk from users trying to recall so many different passwords).
One innovation in cloud security makes this ideal a practical reality: federated identity.
Federated Identity Secures the Cloud
Parsing “federated identity” into its two constituent words reveals the power behind this approach to securing the cloud. The identity is of an individual user, which is the basis for both authentication (the credentials for establishing the user is who he/she claims to be) and authorization (the cloud services permitted for use by specific users). Federation involves a set of standards that allows identity-related information to be shared securely between parties, in this case: the enterprise and cloud-based service providers.
The major advantage of federated identity is that it enables the enterprise to maintain full and centralized control over access to all applications, whether internal or external. Further, federated single sign-on (SSO) allows a user to login once then access all authorized cloud services via a portal or other convenient means of navigation. The IT department essentially controls how users authenticate, including whatever credentials may be required. A related advantage is that, with all access control provisions fully centralized, “on-boarding” (adding new employees) and “off-boarding” (terminating employees) become at once more secure and substantially easier to perform.
Security Tokens
Identity-related information is shared between the enterprise and cloud-based service providers through security tokens; not the physical kind, but as cryptographically signed documents (e.g., XML-based SAML tokens) that contain data about a user. Under this trust model, the good guys have good documents (security tokens) issued from a trusted source; the bad guys never do. For this reason, both the enterprise and the service providers are protected. These security tokens essentially replace the use of a password at each cloud service.
When enabling a federated relationship with different cloud services, there are always two parties: the Identity Provider (IdP) and the Relying Party (RP). The Identity Provider (the enterprise) is the authoritative source of the identity information contained in the security tokens. The Relying Parties (the cloud service providers) establish relationships with one or more Identity Providers and verifies and trusts the security tokens containing the assertions needed to govern access control.
The authoritative nature of and the structured relationship between the two parties are fundamental to federated identity. Based on the trust established between the Enterprise and the cloud service, the Relying Parties have full confidence in the security tokens they receive.
Conclusions
As the popularity of cloud-based services continues to grow, IT departments will increasingly turn to federated identity as the preferred means for managing access control. With federated identity, users and the IT staff both benefit from greater security but also from greater convenience and productivity. Users log in only once, remembering only one strong password, to access all authorized cloud services.
Patrick Harding is CTO for Ping Identity. Harding brings more than 20 years of experience in software development, networking infrastructure and information security to his role with Ping Identity. Previously, Harding was a vice president and security architect at Fidelity Investments where he was responsible for aligning identity management and security technologies with the strategic goals of the business. An active leader in the Identity Security space, he is a Founding Board Member for the Information Card Foundation, a member of the Cloud Security Alliance Board of Advisors, on the steering committee for OASIS and actively involved in the Kantara Initiative and Project Concordia. He is a regular speaker at RSA, Digital ID World, SaaS Summit, Catalyst and other conferences. Harding holds a BS in computer science from the University of New South Wales in Sydney, Australia.