Connected Identity: Benefits, Risks, and Challenges

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.

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.

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 (SMSbased
  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 https://sp1.org/claims/email attribute ID, but the identity provider of the user may
  send it as https://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 idpadmin
  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.
• 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.

The following fundamentals should ideally be supported by an identity broker to be able to
meet future identity and access management requirements:

• Federation protocol agnostic - 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 01

• Transport protocol agnostic - 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).

Figure 02

• Authentication protocol agnostic - 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 03

• Claim transformation - 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).

Figure 04

• Home realm discovery - 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 05

• Multi-option authentication - 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).

Figure 06

• Multi-step authentication - 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 multifactor
  authentication into any of the steps (Figure 7).

Figure 07

• Adaptive authentication - 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.

Figure 08

• Identity mapping - 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 09

• Multiple attribute stores - 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-time provisioning - It should have the ability to provision users to connected
  user stores in a protocol agnostic manner (Figure 11).

Figure 11

• Manage identity relationships - 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

• Trust brokering - Each service provider should identify which identity providers it
  trusts (Figure 13).

Figure 13

• Centralized access control - 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

• Centralized monitoring - 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

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.