18.4.10  Authentication and Authorization

information for the purpose of validation or attribute retrieval. These challenges conspire to suggest a particular approach to access control in the cloud. This approach promotes a shift away from identity-centric authorization, toward authorization based on evaluation of a broad range of transaction characteristics.

Cloud-based PEPs are unlikely to have access to corporate directories or conventional IAM systems to validate security tokens (the latter being tightly bound to directories). Few organizations make these internal systems directly accessible outside their firewall. Even with a VPN bridging on-premise and the cloud, the latency incurred for access makes their use highly impractical.

Directories and IAM systems are certainly deployable in the cloud (though subject to many of the same issues explored here). PEP themselves may have internal directories that are valuable for development and test, but may not be practical for production deployment. However, the real risk with any cloud-resident directory is that it creates a new identity silo that is independent of existing on-premise identity stores. This is clearly undesirable.

Cloud-based PEPs must function independently. They must validate tokens against trust models locally; this collapses much of the traditional functionality of a PDP into PEP basic services, expressed through local policy. This influences both the token types that are practical to use in the cloud and the approach to service authorization.

Weak security tokens – such as user name and password pairs – have no place in the cloud. Public cloud providers are highly visible and accessible targets for system crackers. Brute force attacks against basic access control are trivial to implement and a positive result can often compromise an entire application and its data. Anecdotally, in our own recent deployments of applications on Amazon, we have observed random attack rates exceeding 8,000 attempts in the initial 72 hours of operation. These are largely naive password guessing attacks that may fail to gain access, but succeed in locking out legitimate access. Amazon recognizes this threat and mandates a public key-based, mutual authentication approach to govern access to the root shell of virtual instances. This overrides the traditional basic authentication mechanisms on Unix images.

Every policy governing access to cloud services should adopt a similar approach. It is reasonable to assume that any service residing in the cloud – not just the root shell – will be subject to continuous password guessing attacks. Policies therefore must not assert requirements for basic security token types. WS-Security Username Token Profile [22] and HTTP basic authentication, even using highly randomizing password rules, introduce unacceptable risk. Preferred are multifactor authentication schemes using physical devices that cycle through one time passwords (there are a number of manufacturers of these devices, and Amazon now supports a similar offering). No standardized bindings exist to Web services, so these may require proprietary bindings to HTTP or customized WS-S security tokens to function.

Certificate-based authentication mechanisms – including approaches that leverage PKI such as SAML – are a stronger approach. This provides a strong authentication model that offers a higher level of assurance to parties in a transaction. In addition, certificate extensibility offers authoritative statements from trusted third

parties about attributes associated with a key holder. This can help to decouple authorization from pure identity – which may be impractical to administer at remote cloud sites – and move toward access decisions based on evaluation of a broad number of characteristics – such as organizational unit, membership, rank, etc. In combination with other transactional characteristics communicated by the sender, this can become the basis of formalized authorization models such as Rolebased Access Control (RBAC) (RBAC 2009), and Attribute-based Access Control (ABAC) [15].

SSL/TLS offers optional client-side certificate authentication (in addition to server authentication and channel confidentiality and integrity) [6, 10]. WS-Security x509 Certificate Token Profile [23] articulates a means to sign message contents, binding this to a certificate. Commercial PEPs may include integral CA capabilities for creating and managing certificates.

Certificates associated with identities are typically long lived (usually on the order of years); nevertheless, it remains important to evaluate their current validity. On-premise SOA deployments could often overlook certificate revocation because of in-place security mechanisms and procedures. Cloud-based PEPs, however, by virtue of their global accessibility, must be rigorous in applying revocation checks. This implies regular CRL updates or use of the OCSP protocol. Both are practical in the cloud, but both can place a very high processing cost on clients. CRLs generated by the U.S. Department of Defense have grown so large and unwieldy that simple distribution and evaluation has become largely impractical [7, 27], necessitating a move to OCSP despite its added latency.

Certificates are also not practical containers for authoritative statements about ephemeral attributes or entitlements. SAML tokens, in contrast, support these. SAML has the benefit of offering short lifetime of the assertion (solving revocation issues by forcing an aggressive timeout), a binding to subject evidence (such as key pairs), and providing a means to make statements about acts of authentication, authorization, and arbitrary name/value attributes. Profiles exist describing the use of SAML in HTTP and for Web services.

SAML provides a means to make explicit declarations about authorization. This allows central, on-premise administration of entitlements, issued by a local Security Token Service (STS), relayed with a message to a cloud-based PEP, and evaluated under the trust model in effect. This has the advantage of centralized administration for both on-premise and cloud entitlements.

Despite this, it is a more common practice in cloud architectures to impose a separation of concerns between authentication and authorization. In this model, initial validation of identity claims is made in the enterprise, and thus, close to authoritative directories. Authorization, in contrast, is moved close to services to be enforced on cloud-based PEPs.

There are various approaches for articulating entitlements for suitable for remote, cloud-based evaluation. Native PEP policy can express authorization rules; this approach has the advantage of direct association with services. XACML [21] is a more standardized, albeit complex, alternative. In general, XACML is administered and evaluated in a centralized, cloud-based PDP, accessible to all PEPs

using the XACML Request element embedded into SOAP messages. It is also possible to locally encapsulate XACML within PEP policy context.

Most SOA PEPs also provide the ability to accept Kerberos security tokens in message or transport [23]. In practice, Kerberos has less practicality to the cloud because of the high administration cost of local key management and integration into ticket services.

Finally, while much of this last section concerned validation of sender identity, server-based authentication is also critically important to the client, particularly for clients sending a message to applications hosted in public cloud-provider. SSL and the WS-Security message security model both address this as side effects of the privacy and integrity policy.

18.4.11  Clock Synchronization

Clock synchronization is very important when using short-lived security tokens like SAML or Kerberos tickets. Even minor time deviations between token issuers and PEPs can cause approval problems. Virtual instances inherit their clock from the host, and unpredictable clock skew was a common issue with early virtualization technologies. Virtual cloud PEPs should synchronize clocks regularly with an authoritative time source shared by all participants in a transaction.

18.4.12  Management Challenges in the Cloud

A number of open issues exist around management of PEPs deployed into IaaS facilities. These center around secure persistence, provisioning, and visibility issues in high latency environments (such as those that exist between on-premise operational consoles and cloud providers).

18.4.13  Audit, Logging, and Metrics

Auditing, logging, and accumulation of metrics are important operations in any application infrastructure. In the cloud, these face challenges associated with persistence and collection.

Audits record events of significance; they are distinguished from logs, which document day-to-day operational information. Elements of policy often generate audits explicitly to record important runtime transaction events, such as detection of an attack signature, or even recording of entire message content. Audits also record noteworthy events in the operational lifecycle of the PEP – an update to policy is a typical example. The high value of audit data demands persistence and