Managing Federated Identities in the Cloud

I was visiting the Cloud Security Alliance (CSA) website recently, during one of my downtimes. And they had a new update to their “Security Guidance for Critical Areas of Focus in Cloud Computing V2.1.” I was drawn to the section on federated identity management, a favorite topic of mine, especially during the summer months (don’t ask why).

Managing identities and access control for enterprise applications remains one of the greatest challenges facing IT today. While an enterprise may be able to leverage several Cloud Computing services without a good identity and access management strategy, in the long run extending an organization’s identity services into the cloud is a necessary precursor towards strategic use of on-demand computing services.

So here are the latest recommendations from CSA on federated identities in the Cloud:

CSA Federation Recommendations

In a Cloud Computing environment, federation of identity is key for enabling allied enterprises to authenticate, provide single or reduced Sign-On (SSO), and exchange identity attributes between the Service Provider (SP) and the Identity Provider (IdP). Organizations considering federated identity management in the cloud should understand the various challenges and possible solutions to address them with respect to identity lifecycle management, authentication methods, token formats, and non-repudiation.

(1) Enterprises looking for a cloud provider should verify that the provider supports at least one of the prominent standards (SAML and WS-Federation). SAML is emerging as a widely supported federation standard and is supported by major SaaS and PaaS cloud providers.

(2) Support for multiple standards enables a greater degree of flexibility. Cloud providers should have flexibility to accept the standard federation formats from different identity providers. However most cloud providers as of this writing support a single standard, e.g., SAML 1.1 or SAML 2.0. Cloud providers desiring to support multiple federation token formats should consider implementing some type of federation gateway.

(3) Organizations may wish to evaluate Federated Public SSO versus Federated Private SSO. Federated Public SSO is based on standards such as SAML and WS-Federation with the cloud provider, while Federated Private SSO leverages the existing SSO architecture over VPN. In the long run Federated Public SSO will be ideal, however an organization with a mature SSO architecture and limited number of cloud deployments may gain short-term cost benefits with a Federated Private SSO.

(4) Organizations may wish to opt for federation gateways in order to externalize their federation implementation, in order to manage the issuance and verification of tokens. Using this method, organizations delegate issuing various token types to the federation gateway, which then handles translating tokens from one format to another.

Well, these are the four recommendations from the CSA. Some things to think about during these hot summer days.