208 Cloud Computing
authorization decision statement asserts that a subject is permitted to per-
form action A on resource R given evidence E. The expressiveness of autho-
rization decision statements in SAML is intentionally limited.
A SAML protocol describes how certain SAML elements (including
assertions) are packaged within SAML request and response elements. It
provides processing rules that SAML entities must adhere to when using
these elements. Generally, a SAML protocol is a simple request–response
protocol. The most important type of SAML protocol request is a query. A
service provider makes a query directly to an identity provider over a secure
back channel. For this reason, query messages are typically bound to SOAP.
Corresponding to the three types of statements, there are three types of
SAML queries: the authentication query, the attribute query, and the autho-
rization decision query. Of these, the attribute query is perhaps most impor-
tant. The result of an attribute query is a SAML response containing an
assertion, which itself contains an attribute statement.
Open Authentication (OAuth)
OAuth is an open protocol, initiated by Blaine Cook and Chris Messina, to
allow secure API authorization in a simple, standardized method for various
types of web applications. Cook and Messina had concluded that there were
no open standards for API access delegation. The OAuth discussion group
was created in April 2007, for the small group of implementers to write the
draft proposal for an open protocol. DeWitt Clinton of Google learned of
the OAuth project and expressed interest in supporting the effort. In July
2007 the team drafted an initial specification, and it was released in Octo-
ber of the same year.
OAuth is a method for publishing and interacting with protected data.
For developers, OAuth provides users access to their data while protecting
account credentials. OAuth allows users to grant access to their information,
which is shared by the service provider and consumers without sharing all of
their identity. The Core designation is used to stress that this is the baseline,
and other extensions and protocols can build on it.
By design, OAuth Core 1.0 does not provide many desired features
(e.g., automated discovery of endpoints, language support, support for
XML-RPC and SOAP, standard definition of resource access, OpenID inte-
gration, signing algorithms, etc.). This intentional lack of feature support is
viewed by the authors as a significant benefit. The Core deals with funda-
mental aspects of the protocol, namely, to establish a mechanism for
Chap7.fm Page 208 Friday, May 22, 2009 11:27 AM
Standards for Security 209
exchanging a user name and password for a token with defined rights and to
provide tools to protect the token. It is important to understand that secu-
rity and privacy are not guaranteed by the protocol. In fact, OAuth by itself
provides no privacy at all and depends on other protocols such as SSL to
accomplish that. OAuth can be implemented in a secure manner, however.
In fact, the specification includes substantial security considerations that
must be taken into account when working with sensitive data. With Oauth,
sites use tokens coupled with shared secrets to access resources. Secrets, just
like passwords, must be protected.
OpenID
OpenID is an open, decentralized standard for user authentication and
access control that allows users to log onto many services using the same
digital identity. It is a single-sign-on (SSO) method of access control. As
such, it replaces the common log-in process (i.e., a log-in name and a pass-
word) by allowing users to log in once and gain access to resources across
participating systems.
The original OpenID authentication protocol was developed in May
2005 by Brad Fitzpatrick, creator of the popular community web site Live-
Journal. In late June 2005, discussions began between OpenID developers
and other developers from an enterprise software company named Net-
Mesh. These discussions led to further collaboration on interoperability
between OpenID and NetMesh’s similar Light-Weight Identity (LID) pro-
tocol. The direct result of the collaboration was the Yadis discovery proto-
col, which was announced on October 24, 2005.
The Yadis specification provides a general-purpose identifier for a per-
son and any other entity, which can be used with a variety of services. It pro-
vides a syntax for a resource description document identifying services
available using that identifier and an interpretation of the elements of that
document. Yadis discovery protocol is used for obtaining a resource descrip-
tion document, given that identifier. Together these enable coexistence and
interoperability of a rich variety of services using a single identifier. The
identifier uses a standard syntax and a well-established namespace and
requires no additional namespace administration infrastructure.
An OpenID is in the form of a unique URL and is authenticated by the
entity hosting the OpenID URL. The OpenID protocol does not rely on a
central authority to authenticate a user’s identity. Neither the OpenID pro-
tocol nor any web sites requiring identification can mandate that a specific
Chap7.fm Page 209 Friday, May 22, 2009 11:27 AM
210 Cloud Computing
type of authentication be used; nonstandard forms of authentication such as
smart cards, biometrics, or ordinary passwords are allowed. A typical sce-
nario for using OpenID might be something like this: A user visits a web
site that displays an OpenID log-in form somewhere on the page. Unlike a
typical log-in form, which has fields for user name and password, the
OpenID log-in form has only one field for the OpenID identifier (which is
an OpenID URL). This form is connected to an implementation of an
OpenID client library. A user will have previously registered an OpenID
identifier with an OpenID identity provider. The user types this OpenID
identifier into the OpenID log-in form.
The relying party then requests the web page located at that URL and
reads an HTML link tag to discover the identity provider service URL.
With OpenID 2.0, the client discovers the identity provider service URL by
requesting the XRDS document (also called the Yadis document) with the
content type application/xrds+xml, which may be available at the target
URL but is always available for a target XRI. There are two modes by which
the relying party can communicate with the identity provider:
checkid_immediate and checkid_setup. In checkid_immediate, the rely-
ing party requests that the provider not interact with the user. All communi-
cation is relayed through the user’s browser without explicitly notifying the
user. In checkid_setup, the user communicates with the provider server
directly using the same web browser as is used to access the relying party
site. The second option is more popular on the web.
To start a session, the relying party and the identity provider establish a
shared secret—referenced by an associate handle—which the relying party
then stores. Using checkid_setup, the relying party redirects the user’s web
browser to the identity provider so that the user can authenticate with the
provider. The method of authentication varies, but typically, an OpenID
identity provider prompts the user for a password, then asks whether the
user trusts the relying party web site to receive his or her credentials and
identity details. If the user declines the identity provider’s request to trust
the relying party web site, the browser is redirected to the relying party with
a message indicating that authentication was rejected. The site in turn
refuses to authenticate the user. If the user accepts the identity provider’s
request to trust the relying party web site, the browser is redirected to the
designated return page on the relying party web site along with the user’s
credentials. That relying party must then confirm that the credentials really
came from the identity provider. If they had previously established a shared
Chap7.fm Page 210 Friday, May 22, 2009 11:27 AM
Standards for Security 211
secret, the relying party can validate the shared secret received with the cre-
dentials against the one previously stored. In this case, the relying party is
considered to be stateful, because it stores the shared secret between sessions
(a process sometimes referred to as persistence). In comparison, a stateless
relying party must make background requests using the
check_authentication method to be sure that the data came from the iden-
tity provider.
After the OpenID identifier has been verified, OpenID authentication
is considered successful and the user is considered logged in to the relying
party web site. The web site typically then stores the OpenID identifier in
the user’s session. OpenID does not provide its own authentication meth-
ods, but if an identity provider uses strong authentication, OpenID can be
used for secure transactions.
SSL/TLS
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer
(SSL), are cryptographically secure protocols designed to provide security
and data integrity for communications over TCP/IP. TLS and SSL encrypt
the segments of network connections at the transport layer. Several versions
of the protocols are in general use in web browsers, email, instant messag-
ing, and voice-over-IP. TLS is an IETF standard protocol which was last
updated in RFC 5246.
The TLS protocol allows client/server applications to communicate
across a network in a way specifically designed to prevent eavesdropping,
tampering, and message forgery. TLS provides endpoint authentication and
data confidentiality by using cryptography. TLS authentication is one-
way—the server is authenticated, because the client already knows the
server’s identity. In this case, the client remains unauthenticated. At the
browser level, this means that the browser has validated the server’s certifi-
cate—more specifically, it has checked the digital signatures of the server
certificate’s issuing chain of Certification Authorities (CAs).
Validation does not identify the server to the end user. For true identifi-
cation, the end user must verify the identification information contained in
the server’s certificate (and, indeed, its whole issuing CA chain). This is the
only way for the end user to know the “identity” of the server, and this is the
only way identity can be securely established, verifying that the URL, name,
or address that is being used is specified in the server’s certificate. Malicious
web sites cannot use the valid certificate of another web site because they
Chap7.fm Page 211 Friday, May 22, 2009 11:27 AM
212 Cloud Computing
have no means to encrypt the transmission in a way that it can be decrypted
with the valid certificate. Since only a trusted CA can embed a URL in the
certificate, this ensures that checking the apparent URL with the URL spec-
ified in the certificate is an acceptable way of identifying the site.
TLS also supports a more secure bilateral connection mode whereby
both ends of the connection can be assured that they are communicating
with whom they believe they are connected. This is known as mutual
(assured) authentication. Mutual authentication requires the TLS client-
side to also maintain a certificate. TLS involves three basic phases:
1. Peer negotiation for algorithm support
2. Key exchange and authentication
3. Symmetric cipher encryption and message authentication
During the first phase, the client and server negotiate cipher suites,
which determine which ciphers are used; makes a decision on the key
exchange and authentication algorithms to be used; and determines the
message authentication codes. The key exchange and authentication algo-
rithms are typically public key algorithms. The message authentication
codes are made up from cryptographic hash functions. Once these decisions
are made, data transfer may begin.
7.7 Chapter Summary
In this chapter we have discussed some of the more prevalent standards used
in cloud computing. Although we have not analyzed each standard in
depth, you should now have a feel for how and why each standard is used
and, more important, an understanding of why they have evolved. Stan-
dards are important, to be sure, but most of these standards evolved from
individuals taking a chance on a new innovation. As these innovative tech-
niques became acceptable to users and implementers, more support for the
technique followed. At some point, enough support was present to make
the innovation be considered a “standard,” and groups formalized protocols
or rules for using it. Such a “standard” is used until more new innovation
takes us elsewhere.
Chap7.fm Page 212 Friday, May 22, 2009 11:27 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.