Many pundits say that you must pick a Cloud Provider and trust them. I beg to differ. First off why should we trust the Cloud Provider? A Cloud Consumer wants to leverage the Cloud Provider’s capabilities for functionality and scale where it makes but why should this equate to blind naïve trust? And anyway, what specifically is the Cloud Consumer trusting the Cloud Provider? As the old country music song says, “In God, we trust, all others pay cash.”
Instead of blindly trusting the Cloud provider to do the right thing (and a glance at any recent news will show how hard this is in practice) it makes more sense for the Cloud Consumer, e.g. you, to limit how much control you choose to pass to the Cloud Provider. One technique for accomplishing this is to retain control of User Account Management at the Cloud Consumer site.
When the Cloud Consumer retains the responsibility for User Account Management, the security architecture gains in several ways:
- Choice of authentication techniques
- Freshest, most accurate data, and the ability to leverage enterprise provisioning
- Visibility into account usage
- Auditability of user account stores
- Verification of account ownership
To realize these benefits the Cloud Consumer company must ensure that their local user account information and sessions can be integrated with the Cloud Provider. A starting point for most of these efforts relies on using SAML as a strong, standard based method to integrating Cloud Consumers with Cloud Providers. The Cloud Consumer plays the role of the SAML Identity Provider and the Cloud Provider plays the roles of the SAML Relying Party. This style enables the Cloud Consumer to retain control of the User Accounts and issue standards-based assertions for the Cloud Provider to make run time decisions based on authentication, authorization and attribute sharing scenarios.
Enterprises have demonstrated the desire to explore a wide variety of authentication techniques, driven in some cases by authentication strength and other times by constraints. Below is a list of authentication methods supported in the SAML standard:
- IP Password
- Mobile One Factor Unregistered
- Mobile Two Factor Registered
- Mobile One Factor Contract
- Mobile Two Factor Contract
- Password Protected transport
- Previous Session
- Public Key X.509
- Public Key PGP
- Public Key SPKI
- Public Key XML Digital Signature
- Smartcard PKI
- Software PKI
- Telephony Nomadic
- Telephony Personalized
- Telephony Authenticated
- Secure remote password
- SSL/TLS Client Authentication
- Time Sync Token
First off, holy protocol soup, Batman! What this clearly shows is that authentication remains a moving target. Recent troubles at RSA (http://online.wsj.com/article/SB10001424052702304906004576369990616694366.html) show there is not an end in sight to this trend. Authentication is clearly something that enterprises will continue to iterate on and attempt to improve upon.
As security architects, we should expect authentication technologies to continue to evolve and support a wide variety of techniques. The architecture should insulate the consuming applications like Cloud Providers from this change, and the standard SAML tokens and protocols give us a way to do this.
The enterprise user’s credential, whether 2 Factor, Password, PKI or one of the myriad of other choices is insulated from the integration between the Cloud Consumer and Service provider. This separation of concerns means that changes in authentication technology or in Cloud application should not ripple through the architecture. The separation of authentication concerns from the Cloud creates a pragmatic way to address the enterprise authentication and credential choice locally at the Cloud Consumer.
To enable this separation, the security architect should work on design patterns along the following integration points:
- Identify enterprise user credential types in use for Cloud Applications
- Cloud Consumer
- For the Credential types in play identify where and how they can be integrated with Access software such as SAML Identity Providers
- Identify what use cases and level of support is required from the Identity Provider – authentication, authorization, and attribute sharing
- Cloud Provider
- Agree upon protocol and formats and what authentication context is required to propagate to the Cloud provider.
- Ensure that the Cloud Provider targets can consume the selected identity use cases – authentication, authorization and attribute sharing
- Ensure that session management implements a consistent policy
The role of the SAML provider providing access in this case play a dual role crossing the chasm from byzantine enterprise authentication to more open Cloud Providers while not losing the fidelity of the original session.
For further research on how this may apply to your planned Cloud application scenarios, the Dynamic Perimeter site shows a number of real world Use cases and integration examples
Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com.