Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
BY FRANK LEYMANN
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGESBY PRABATH SIRIWARDENADIRECTOR - SECURITY ARCHITECTURE, WSO2
TABLE OF CONTENTS
1. Introduction................................................................................................................................................
2. Breaking Silos in a Connected Business..........................................................................................
3. Identity Broker Pattern Benefits........................................................................................................
4. Identity Broker: Key Fundamentals...................................................................................................
5. Conclusion...................................................................................................................................................
6. References...................................................................................................................................................
03
04
04
06
14
14
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
02
1. INTRODUCTION
Today, the global Internet economy is estimated to be around of $10 trillion US dollars; in
the next couple of years, almost half the world’s population (about 3 billion people) is set
to get their hands on the Internet. And it doesn’t just end there - in 2008, the number of
things connected to the Internet exceeded the number of people on earth. To put this into
perspective, over 12.5 billion devices were connected to the Internet in 2012. It is estimated
that at least 50 billion devices will be connected to the Internet by end-2020.
Connected devices have existed in one form or another since the introduction of the first
computer network and consumer electronics. However, global connectivity started to take
shape only after the Internet emerged. In the 1990s the possible communication between
people and machines and interaction via machines was only a concept; today it’s a reality
that’s continuing to evolve.
The concept of ‘identity’ is not confined to just humans anymore, but rather represents both
humans and ‘things’. The identity of things (IDoT) is an effort that involves assigning unique
identifiers (UID) with associated metadata to devices and objects (things), enabling them
to connect and communicate effectively with other entities over the Internet.
The metadata associated with the unique identifier collectively defines the identity of an
endpoint. IDoT is an essential component of the Internet of things (IoT), in which almost
anything imaginable can be addressed and networked for exchange of data online. In this
context, a thing can be any entity, both physical and logical objects, that has a unique
identifier and has the ability to transfer data over a network.
The definition of identity has evolved with IoT and cannot be defined by just attributes or
claims. It can be further refined by patterns or behaviors. Yet, the complete picture of a
given entity’s identity is unavailable. Moreover, the privacy of data migration and ownership
is another challenge we face in today’s connected world. For example, the connected car is
among the millions of Internet-connected devices available today - it can collect and store a
vast amount of data that can go well beyond the vehicle owner’s personal preferences and
settings; the car can collect driver data such as travel routes, travel destinations, car speeds,
driver behavior, and commute patterns among many other nuggets of information.
All of the data collected and stored by these IoT devices are helping to create a “virtual
identity” for each and every user. While this user-generated data will most likely last forever,
connected cars and all the other Internet-connected devices will eventually phase out.
In the context of the connected car, it would lead to important questions concerning car
owners and their data, such as how and where this data is stored, the fate of the already
collected data when the owner buys a new car, and the possibility of transferring this data
to another connected car even if the car is built by a different manufacturer. Connected car
data and user preferences are primarily stored in cloud-based silos.
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
03
There are no universal standards or best practices among car manufacturers or industry
players for collecting, storing, and managing data of connected car owners. Moreover,
there are no universal standards or best practices to manage the ‘identity’ of connected car
owners, which includes the storage and export of personal preferences and user history.
2. BREAKING SILOS IN A CONNECTED BUSINESS
Identity silos create a lot of friction in the connected business. One way to reduce friction,
while keeping data in silos as well as the ownership of data is to expose identity data
via APIs to help users establish a clear identity. By doing this, they would be able to, for
instance, relate driving patterns with sleeping patterns or daily food consumption patterns
with sleeping patterns, etc. The impending challenge, however, is propagating end-user
identity across these APIs; therefore, building a protocol agnostic security model is key
to ensure connected identity. The security model of one entity should be compatible with
other connected devices. This would amount to building a point-to-point security model
that would lead to the spaghetti identity anti-pattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world.
Even in the past, most enterprises have expanded via acquisitions, mergers, and
partnerships, thereby including more external users into their system. An analyst firm has
even predicted that by 2020 around 60% of all digital identities interacting with enterprises
will come from external identity providers.
Each external identity provider can be treated as an identity silo and identity data is
shared via APIs. The identity consumer, or service provider, must trust the identity provider
to accept a given user identity. Beyond the trust, both the service provider and identity
provider must speak the same language to establish trust and then transport identity
data. In the case of a service provider that doesn’t comply with the identity token sharing
protocol supported by the identity provider, you would either need to fix the identity
provider’s end to speak the same language of the service provider, or vice versa.
3. IDENTITY BROKER PATTERN BENEFITS
The connected business space today involves a very dynamic environment. An enterprise’s
goal is to reach out to as many customers, partners, distributors, and suppliers that would
result in more business interactions and subsequently translate to revenue growth. Their
ultimate goal, however, should be to make the business more accessible and reactive rather
than just simply integrating technological silos. Ensuring there’s no friction in building
connections between business entities comes at a price and with certain limitations - the
cost of provisioning a service provider or an identity provider into the system could be high
due to protocol incompatibilities. In addition, building point-to-point trust relationships
between service providers and identity providers is not scalable.
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
04
With the identity bus or the identity broker pattern, a given service provider is not
coupled to a specific identity provider as well as to a given federation protocol. The broker
maintains the trust relationships between each entity as well as identity tokens between
multiple heterogeneous security protocols. It can further enforce access controlling,
auditing, and monitoring. Given the ongoing evolution in standards for identity federation
and the lack of proper standards to manage and propagate device identities, the identity
broker will play a key role in building a common, connected identity platform in a protocol
agnostic manner.
The identity broker pattern has the following key benefits:
• Frictionless introduction of a new service provider - This requires the enterprise to
register the service provider at the identity bus and at that point pick the identity
providers it trusts. It doesn’t need to add the service provider configuration to each
and every identity provider.
• Frictionless removal of an existing service provider - The user would need to remove
the service provider from the identity bus and it’s not required to remove the service
provider from each and every identity provider.
• Frictionless introduction of a new identity provider - The user would need to register
the identity provider at the identity bus and it will be available to any service provider.
• Easy removal of an existing identity provider - The user would need to remove the
identity provider from the identity bus.
• Frictionless enforcing of new authentication protocols - In the event the enterprise
needs to authenticate users with both username/password and duo-security (SMS-
based authentication), it would only need to add that capability to the identity bus
and at that point pick the required set of authentication protocols against a given
service provider at the time of service provider registration. Each service provider can
pick how it wants to authenticate users at the identity bus.
• Claim transformations - The service provider may read the user’s email address from
the http://sp1.org/claims/email attribute ID, but the identity provider of the user may
send it as http://idp1.org/claims/emai. The identity bus can transform the claims it
receives from the identity provider to the format expected by the service provider.
• Role mapping - The service provider needs to authorize users once they are logged
in. What the user can do at the identity provider is different from what the same user
can do at the service provider. The user’s roles from the identity provider define what
he/she can do at the identity provider. The service provider’s roles define the things a
user can do at the service provider. The identity bus is capable of mapping the identity
provider’s roles to the service provider’s roles. For example a user may bring an idp-
admin role from his identity provider in a SAML response and the identity bus will find
the mapped service provider role corresponding to this (e.g. sp-admin) and will add
that into the SAML response that will return to the service provider from the identity
bus.
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
05
• Just-in-time provisioning - Given the identity bus is at the forefront of all identity
transactions, it can provision all external user identities to an internal user store.
• Centralized monitoring and auditing and centralized access control.
• Easy introduction of a new federation protocol - If an enterprise has a service provider
or an identity provider that supports a proprietary federation protocol, you only need
to add that capability to the identity bus.
4. IDENTITY BROKER: KEY FUNDAMENTALS
The following fundamentals should ideally be supported by an identity broker to be able to
meet future identity and access management requirements:
• Federationprotocolagnostic - As illustrated in Figure 1, this should not be
coupled with a specific protocol like SAML, OpenID Connect, WS-Federation, etc.
WSO2 Identity Server (WSO2 IS) enables connecting to multiple identity as well as
service providers over heterogeneous identity federation protocols, and transform ID
tokens between multiple heterogeneous federation protocols.
Figure 1
• Transportprotocolagnostic - This should not be coupled with a specific transport
protocol like HTTP or MQTT and should have the ability to read from and write to
multiple transport channels (Figure 2).
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
06
SAML, OIDC,OpenID, OAuth2.0, WS-Federation
SAML, OIDC,OpenID, OAuth2.0, WS-Federation
WSO2 IS
Figure 2
• Authenticationprotocolagnostic-As explained in Figure 3, this should not be couple
with a specific authentication protocol, username/password, FIDO, OTP, etc. It should
also include pluggable authenticators.
Figure 3
• Claimtransformation- It should have the ability to transform identity provider specific
claims into service provider specific claims and vice versa, thus supporting simple
claim as well as complex transformations, e.g. a complex claim transformation would
be to derive the age from the date-of-birth identity provider claim - or concatenate
first name and last name claims from the identity provider to form the full name
service provider claim (Figure 4).
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
07
User store
WSO2 IS
UsernamesPassword
Duo Secuurity
FIDD
MePin
HTTP, MQTTWSO2 ISHTTP, MQTT
Figure 4
• Homerealmdiscovery-As shown in Figure 5, it should have the ability to find the
home identity provider that corresponds with the incoming federation request by
looking at certain attributes in the request. The discovery process should be pluggable
and ensure filter-based routing.
Figure 5
• Multi-optionauthentication- It should have the ability to present multiple login
options to the user by the service provider. Based on the service provider who initiates
the authentication request, the identity broker will present login options to the user
(Figure 6).
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
08
http://sp1/firstName
http://idp1/firstName
WSO2 IS
foo.com
WSO2 IS
hrd-foo.com
Figure 6
• Multi-stepauthentication-It should have the ability to present multiple step
authentication (MFA) to the user by the service provider. MFA is an instance of
multiple step authentication where you plug in authenticators that support multi-
factor authentication into any of the steps (Figure 7).
Figure 7
• Adaptiveauthentication-As described in Figure 8, the ability to change
authentication options based on the context should be available. The identity broker
should also have the ability to derive context from the authentication request itself as
well as from other supportive data.
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
09
UsernamesPassword
WSO2 IS
SP1
WSO2 IS
WSO2 IS
SP1
SP2
WSO2 IS
Figure 8
• Identitymapping-It should have the ability to map identities between different
identity providers; the user should be able to maintain multiple identities with various
identity providers and switch between identities when logging into multiple service
providers (Figure 9).
Figure 9
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
10
UsernamesPassword
WSO2 IS WSO2 IS
+
SP1
• Multipleattributestores-As illustrated in Figure 10, it should have the ability to
connect to multiple attribute stores and build an aggravated view of the end-user’s
identity.
Figure 10
•Just-in-timeprovisioning-It should have the ability to provision users to connected
user stores in a protocol agnostic manner (Figure 11).
Figure 11
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
11
WSO2 ISSP1
WSO2 IS
SPIdP
•Manageidentityrelationships-As shown in Figure 12, it should have the ability to
manage identity relationships between different entities and, based on this, take
authentication and authorization decisions. A given user can belong to a group or role,
and be the owner of devices of multiple platforms; a device could have an owner, an
administrator, a user, and so on.
Figure 12
•Trustbrokering- Each service provider should identify which identity providers it
trusts (Figure 13).
Figure 13
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
12
WSO2 IS
SP1
SP2
WSO2 IS
•Centralizedaccesscontrol-This component refers to who gets access to which user
attribute and the specific service provider’s resources the user can access (Figure 14).
Figure 14
•Centralizedmonitoring- It should have the ability to monitor and generate statistics
on each identity transaction and ensure it flows through the broker. WSO2’s analytics
platform, WSO2 Data Analytics Server (DAS), offers a connected analytics engine that
can carry out batch, real-time, and predictive analytics (Figure 15).
Figure 15
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
13
Idp
SP
WSO2 IS
WSO2 DAS
PDP
Idp
SP
WSO2 IS
PDP
WSO2 Identity Server provides a comprehensive security model based on OAuth 2.0 to
secure access to APIs. Further, the XACML 3.0 support in WSO2 Identity Server can be
leveraged to build a fine-grained access control model. WSO2 Identity Server along with
WSO2 API Manager can build a comprehensive API security ecosystem for an enterprise.
5. CONCLUSION
Connected devices is not a concept anymore. In fact, it’s evolving at a dynamic pace.
Enterprises too need to adapt and find ways to manage the challenges that follow too.
Ultimately, an enterprise’s goal is to increase and expand business interactions with the
parties it deals with and eventually translate these to revenue growth. The real challenge,
however, is to find ways to make their businesses more accessible and reactive rather
than just simply integrating technological silos. When doing so, security and identity
management plays a critical role in efforts to enhance end-user experience.
WSO2 efficiently undertakes the complex task of identity management across enterprise
applications, services, and APIs by utilizing the full breadth of the WSO2 platform. The
WSO2 open source model avoids vendor lock-in and enables integration across systems,
acting as a fully functional enterprise identity bus.
6. REFERENCES
• The Internet of Things (The MIT Press Essential Knowledge series), http://www.
amazon.com/Internet-Things-Press-Essential-Knowledge/dp/0262527731
• Future Crimes: Everything Is Connected, Everyone Is Vulnerable and What We Can Do
About It, http://www.amazon.com/Future-Crimes-Everything-Connected-Vulnerable/
dp/0385539002
• http://www.programmableweb.com/news/identity-and-access-management-iam-will-
greatly-impact-future-connected-car-sales/analysis/2014/08/20
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
14
ABOUT THE AUTHOR
ABOUT WSO2
Check out more WSO2WhitePapers and WSO2CaseStudies.
For more information about WSO2 products and services,
please visit http://wso2.com or email [email protected]
CONNECTED IDENTITY: BENEFITS, RISKS, AND CHALLENGES ©2016 WSO2
PrabathSiriwardena
Director - Security Architecture,
WSO2
Prabath has over 11 years of industry experience that currently involves providing security
architecture solutions to many of WSO2’s key customers. He has spoken at several global
user conferences including ApacheCon, OSCON, QCon, WSO2Con, and European Identity
Conference, among others. He has also authored four books related to Apache Maven,
enterprise integration, and API security. Prabath is an Apache Axis2 PMC member as well
as a member of OASIS Identity Metasystem Interoperability (IMI) TC,OASIS eXtensible
Access Control Markup Language (XACML) TC, OASIS Security Services (SAML) TC, OASIS
Identity in the Cloud TC and OASIS Cloud Authorization (CloudAuthZ) TC.
WSO2 is the only company that provides a completely integrated enterprise application
platform for enabling a business to build and connect APIs, applications, web services,
iPaaS, PaaS, software as a service, and legacy connections without having to write code;
using big data and mobile; and fostering reuse through a social enterprise store. Only with
WSO2 can enterprises use a family of governed secure solutions built on the same code
base to extend their ecosystems across the cloud and on mobile devices to employees,
customers, and partners in anyway they like. Hundreds of leading enterprise customers
across every sector—health, financial, retail, logistics, manufacturing, travel, technology,
telecom, and more—in every region of the world rely on WSO2’s award-winning, 100% open
source platform for their mission-critical applications. To learn more, visit http://wso2.com
or check out the WSO2 community on the WSO2 Blog, Twitter, LinkedIn, and Facebook.