Providing fine grained access to SalesForce and Google Apps

Companies that move to Cloud Providers like Salesforce and Google apps quickly discover that part of the migration involves revisiting their security model. Authentication, authorization, account management, and federation are on the menu of activities for most organizations as they strive to garner the cost savings and distribution of the Cloud and retain some level of control of users and assets.

Cloud consumers can insulate their implementations from the vagaries of proprietary identity implementations through using standards. In most cases, SAML represents a logical starting point for conveying identity information from the Cloud Consumer to the Cloud Provider. SAML is a well adopted industry standard that is available in many commercial and open source implementations. SAML is referenced by many industry groups such as the Cloud Security Alliance.

SAML’s architecture lends itself to Cloud scenarios, because the Cloud Consumer (enterprise) and Cloud Provider fit naturally into the core SAML roles. The primary roles in a SAML architecture are the Identity Provider (IdP) who asserts information about a user, and Relying Party (RP), who acts on the information for the service provider, such as the Cloud Provider. Because SAML was designed with this separation of roles in mind, it maps cleanly onto Cloud Deployment models.

Cloud consumers get three main benefits from this architecture:

Cloud consumers retain management and provisioning of user accounts, providing the Cloud applications with the freshest and most accurate data on users

Applications are built using peer reviewed access control protocols instead of home grown or proprietary access controls

Cloud consumers implement a standards-based identity interface which simplifies integration to other vendors

Both Google and Salesforce support SAML to communicate identity information from the Cloud Consumer to the Cloud Provider, so the Cloud Consumer can leverage their existing on-premise enterprise directory and SAML IDentity Provider to serve identity information to two different Cloud providers.

Access Control Model
SAML provides a standards-based means to get identity information to the Cloud provider in a reliable way, but the Cloud applications’ business logic and data will determine what the proper access control and authorization rules should be.

The basic algebra of authorization is pretty straightforward: authorization rules govern the interaction between a subject (such as a user), and an object (such as web service or database), based on the action requested, in a certain context (sometimes called scope). These four primitives - Subject, Object, Action, and Context - are evaluated against conditions and chains of responsibilities.

Where the difficult decisions lie for the security architect is to identify the level of granularity to apply the authorization rules. To simply grant or deny access to anyone in the enterprise directory to access the Cloud Provider is very likely too coarsely grained. In most cases authorization rules are more context specific. This means that SAML and other identity standards perform the crucial function of moving the identity data to the authorization logic, but the application must still assemble the request, and map the request against the target’s authorization rules. Many applications use Role Based Access Control (RBAC) for this mapping, and SAML and identity providers do not replace this.

Integration Concerns
The two basic roles Identity Provider and Relying Party use SAML to communicate, so their conversation is supported via that standard. There are two areas that require additional work for an integrated solution. Note for an extended demo of these concepts in practice, please see Cloud Access 360 demo

The Identity Provider issues the SAML assertion based on the session and use profile in the enterprise directory. The Relying Party validates the SAML assertion and initiates a session on the Cloud Provider application. This means that integration work is required to ensure the Identity Provider is integrated to the enterprise directory; and the Relying Party is integrated to the Cloud Provider. In the latter case, Cloud Providers like Google and Salesforce.com have done the integration work to ensure that their applications are integrated, but this still leaves Cloud consumers with an integration effort towards ensuring that the Identity Provider can communicate with the Enterprise directory.

The next Integration concern is to get the proper information to the Relying Party to make its authorization decision. This is likely to be application-specific, but one thing is for sure, simply being logged on to the Cloud Consumer’s enterprise directory is likely to be insufficient to access Cloud Provider applications, so the SAML assertion must be enriched with additional information from the enterprise directory such as Group, Role and other attributes.

To accomplish this, the Identity Provider and Relying Party must agree upon a schema for communicating the attributes needed to make the authorization decision. In some cases, the Cloud Provider can act simply on the Group and Role information, however increasingly authorization is more subtle and specific, and additional attributes are needed to convey permissions such as allowable Create, Read, Update and Delete on objects.

Once the mapping of the Group, Role and/or attributes in the enterprise directory to the Cloud Provider permissions is completed, these must be exchanged and typically issued in a way that supports Single Sign On. One way to accomplish this in Salesforce.com is to exchange the grant_type Assertion via SAML for the Salesforce.com access token. The next step is to ensure the mapping extends to the Salesforce.com permission grants, these typically include permissions such as Manage Billing, Manage Call Centers, Manage Users, Transfer Record, and Weekly Export Data. What the Cloud Consumer gains in this case is to retain the user management on premises via the enterprise directory and gain the capabilities of the Salesforce Cloud.

In the case of Google Apps, there are a variety of token types supported, the SAML token is likely to be exchanged for an oauth token. The oauth token uses the consumer key to convey the authorized users’ information to the Google Cloud Provider. The token maps to the Google permission model, for example to show if a given user is able to Read a Calendar, Update a Calendar, or Read Calendar details.

Conclusion
The combination of SAML roles such as Identity provider and Relying party provide the separation of duties that works well in Cloud Environments. The Cloud Consumers retain user management and convey this information to the Cloud Provider via interoperable, open standards. There are two areas of integration in the Identity provider and Relying party which require integration to the enterprise directory and Cloud Provider respectively.

Companies must also integrate the Roles, Group and attribute information from their user accounts in the enterprise directory to the Cloud Provider access models. This requires some additional review of business processes and use cases to complete, but the end result allows the Cloud consumer a level of user control that drives the authorization decisions made in the Cloud

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.