Presence in the Cloud 139
5.3.3 Presence Enabled
What does it mean to be “presence-enabled”? The basic concept is to show
availability of an entity in an appropriate venue. Some modern applications
aggregate presence information about all of a person’s various connections.
For communication devices such as phones and applications such as IM,
presence information is often built into the device itself. For less communi-
cation-centric applications, such as a document or web page, presence may
be gathered by means of a web services API or channeled through a presence
daemon. Providing presence data through as many avenues as possible is in
large measure the responsibility of a presence engine, as described below.
The presence engine acts as a broker for presence publishers and sub-
scribers. A presence broker provides aggregation of information from many
sources, abstraction of that information into open and flexible formats, and
distribution of that information to a wide variety of interested parties. In
the realm of presence, the qualities of aggregation, abstraction, and distribu-
tion imply that the ideal presence broker is trustworthy, open, and intelli-
gent. As presence becomes more prevalent in Internet communications,
presence engines need to provide strong authentication, channel encryp-
tion, explicit authorization and access control policies, high reliability, and
the consistent application of aggregation rules. Being able to operate using
multiple protocols such as IMPS, SIMPLE, and XMPP is a basic require-
ment in order to distribute presence information as widely as possible.
Aggregating information from a wide variety of sources requires presence
rules that enable subscribers to get the right information at the right time.
5.3.4 The Future of Presence
It will remain to be seen if XMPP is the future of cloud services, but for now
it is the dominant protocol for presence in the space. Fixing the polling and
scaling problems with XMPP (which we will discuss in Chapter 8, has been
challenging but has been accomplished by providers such as Tivo, and the
built-in presence functionality offers further fascinating possibilities. Pres-
ence includes basic availability information, but it is extensible and can also
include abilities such as geo-location. Imagine cloud services taking differ-
ent actions based on
where
the client initiated a connection.
Chap5.fm Page 139 Friday, May 22, 2009 11:25 AM
140 Cloud Computing
5.3.5 The Interrelation of Identity, Presence, and Location in
the Cloud
Digital identity
refers to the traits, attributes, and preferences on which one
may receive personalized services. Identity traits might include government-
issued IDs, corporate user accounts, and biometric information. Two user
attributes which may be associated with identity are presence and location.
Over the last few years, there has been an aggressive move toward the con-
vergence of identity, location, and presence. This is important because a
standard framework tying identity to presence and location creates the abil-
ity to develop standards-based services for identity management that incor-
porate presence and location. Identity, presence, and location are three
characteristics that lie at the core of some of the most critical emerging tech-
nologies in the market today: real-time communications (including VoIP,
IM, and mobile communications), cloud computing, collaboration, and
identity-based security.
Presence is most often associated with real-time communications sys-
tems such as IM and describes the state of a user’s interaction with a system,
such as which computer they are accessing, whether they are idle or work-
ing, and perhaps also which task they are currently performing (reading a
document, composing email etc.). Location refers to the user’s physical loca-
tion and typically includes latitude, longitude, and (sometimes) altitude.
Authentication and authorization mechanisms generally focus on determin-
ing the “who” of identity, location defines the “where,” and presence defines
the “what”—all critical components of the identity-based emerging technol-
ogies listed above, including cloud computing.
5.3.6 Federated Identity Management
Network identity is a set of attributes which describes an individual in the
digital space. Identity management is the business processes and technolo-
gies of managing the life cycle of an identity and its relationship to business
applications and services. Federated identity management (IdM) refers to
standards-based approaches for handling authentication, single sign-on
(SSO, a property of access control for multiple related but independent
software systems), role-based access control, and session management across
diverse organizations, security domains, and application platforms. It is a
system that allows individuals to use the same user name, password, or other
personal identification to sign on to the networks of more than one entity in
order to conduct transactions. Federation is enabled through the use of
Chap5.fm Page 140 Friday, May 22, 2009 11:25 AM
Presence in the Cloud 141
open industry standards and/or openly published specifications, such that
multiple parties can achieve interoperability for common use cases. Typical
use cases involve things such as cross-domain, web-based single sign-on,
cross-domain user account provisioning, cross-domain entitlement manage-
ment, and cross-domain user attribute exchange.
Single sign-on enables a user to log in once and gain access to the
resources of multiple software systems without being prompted to log in
again. Because different applications and resources support different
authentication mechanisms, single sign-on has to internally translate to and
store different credentials compared to what is used for initial authentica-
tion. The most widely implemented federated IdM/SSO protocol standards
are Liberty Alliance Identity Federation Framework (ID-FF), OASIS Secu-
rity Assertion Markup Language (SAML), and WS-Federation.
Within a typical cross-carrier internetworking environment, federated
IdM may be implemented in layers. For converged IP services, federated
IdM may involve separate authentications at the application layer and the
network layer. Increasingly, the application-layer authentications rely on any
or all of the federated IdM standards mentioned above.
5.3.7 Cloud and SaaS Identity Management
As SaaS vendors and their customers sort through the security implications
of the hybrid on-demand/on-premises model for cloud applications, they
face a number of very interesting identity management challenges. The typ-
ical large enterprise IT shop has relatively mature production implementa-
tions for standard identity management functionalities such as user
authentication, single sign-on, user management, provisioning/deprovision-
ing, and audit. Because these implementations were designed and deployed
to support users accessing applications running inside the enterprise, they
often do not transition well to a model that calls for users to access applica-
tions (such as Salesforce.com and GoogleApps) which are hosted outside the
corporate firewall.
With the advent of cloud computing and the identity requirements
that corporate IT departments are putting on SaaS providers, the line
between on-demand applications and on-premises applications is blurring,
and a hybrid model is emerging in which the goal is closer integration of
SaaS applications and functionality within enterprise IT infrastructure.
The result is that sometimes corporate IT may have deployed an effective
common model for identity management within the enterprise, but that
Chap5.fm Page 141 Friday, May 22, 2009 11:25 AM
142 Cloud Computing
common model breaks down when requirements call for integration with
on-demand applications. This breakdown comes in the form of proliferat-
ing on-demand user name and password accounts for users, manual pro-
cesses for provisioning and deprovisioning users to on-demand
applications, limited audit visibility across on-demand applications, and
constraints on data integration between external and internal applications.
With the success of single sign-on inside the enterprise, users are call-
ing for interoperability outside the enterprise’s security domain to out-
sourced services, including business process outsourcing (BPO) and SaaS
providers, and trading partners, as well as within the enterprise to affiliates
and subsidiaries.
As a result of business demands that employees be able to traverse the
Internet with highly sensitive data, using secure connections that protect the
user, the enterprise, and the service provider, Internet-based SSO has seen a
substantial increase over the last few years. There are many options to con-
sider for delivering a SSO that works over the Internet. Choosing the right
technology is crucial to successfully implementing federated identity man-
agement and mitigating long deployment times. The typical options for
SSO are either a proprietary SSO (web agents) or standards-based SSO
(identity federation). The idea of SSO has been around for years; it was the
reason why enterprise portal software was invented in the late 1990s, and
why many companies built proprietary SSO solutions. However, propri-
etary solutions that had to be rolled out by IT departments proved to have
serious time, cost, complexity, and security implications.
In June 2008, Salesforce.com disclosed that it was using Security Asser-
tion Markup Language (SAML), an open identity federation standard from
OASIS, to implement SSO. The key benefit of using SAML instead of a
proprietary SSO is that with SAML the same solution a customer uses for
SSO to Salesforce.com can be used with GoogleApps or any of the other
hundreds of companies that now support the SAML standard. This elimi-
nated the need for multiple one-offs for SSO. The fact that the leading on-
demand application made the move to SAML is a signal that the SaaS/on-
demand community is on the path to adopting common models for iden-
tity management and security. SAML is the dominant web services standard
for federated identity management today. It defines a set of XML formats
for representing identity and attribute information, as well as protocols for
requests and responses for access control information.
Chap5.fm Page 142 Friday, May 22, 2009 11:25 AM
Presence in the Cloud 143
The key principle behind SAML is an
assertion,
a statement made by a
trusted party about another. For example, a federated identity management
server produces assertions about the identity and rights of users. An indi-
vidual application does not need to have direct access to the user repository
or trust a user—it only needs to know and trust the assertions source.
Assertions can be encoded in browser requests or included in web services
transactions, enabling log-ins for both person-to-machine and machine-to-
machine communications. This was another first, the ability to use the
same standards protocol for both back-end transactions and web portal
access control.
5.3.8 Federating Identity
Identity federation standards describe two operational roles in an Internet
SSO transaction: the identity provider (IdP) and the service provider (SP).
An IdP, for example, might be an enterprise that manages accounts for a
large number of users who may need secure Internet access to the web-
based applications or services of customers, suppliers, and business part-
ners. An SP might be a SaaS or a business-process outsourcing (BPO) ven-
dor wanting to simplify client access to its services. Identity federation
allows both types of organizations to define a trust relationship whereby
the SP provides access to users from the IdP. There are four common meth-
ods to achieve identity federation: Use proprietary solutions, use open
source solutions, contract a vendor to do it, or implement a standards-
based federated solution.
Many attempt to write their own solution, only to find out there is a
huge learning curve and a very high risk that the solution will be incompat-
ible with the external applications and partners they want to connect to.
Proprietary solutions rarely scale to connect with multiple partners. Open
source libraries are often missing key abilities such as partner enablement
and integration, rarely support the SAML 2.0 communication standard,
and require significant continuous effort to adapt and maintain. If you
choose to contract an identity management stack vendor, the federation
component of the stack vendor’s suite is usually the newest, least mature
component, and its connection capabilities may be very limited in scope.
The most successful way to achieve identity federation is to choose a
standalone federation vendor, whose sole focus is to provide secure Internet
SSO through identity federation to numerous applications and partners.
These vendors provide best-of-breed functionality, and they will work with
Chap5.fm Page 143 Friday, May 22, 2009 11:25 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.