Identity Bridging

This topic describes how the gateway handles identity bridging.
This topic describes how the
Layer7 API Gateway
handles identity bridging.
The Identity Silo Problem
Controlling access to applications exposed as web services requires the authentication and authorization of requesting identities. Authentication involves validating the credentials that are presented, while authorization involves granting access, rights, or entitlements based on the interpretation of the authentication results. For consistent management, identities are typically stored in the same security domain as the application. During the authentication and authorization process, the exact elements in an identity are matched to the functional requirements of the services served by the identity provider. Identities from one identity provider rarely have much relevance outside of their local security domain. This leads to the creation of “identity silos”. Identity silos are a serious problem for enterprises wanting to integrate applications residing in different security domains.
If a legitimate requestor authenticates against a corresponding identity provider in one identity silo, its identity, or any evidence of the authentication may have no relevance when requesting access to another web service in another identity silo inside or outside the enterprise. Disparate identity providers within an enterprise or between partners complicates the authentication and authorization process, resulting in broken integrations and failed authorizations in one silo even when authentication succeeded in another silo.
Identity Bridging for Cross-Domain Application Integration
Identity bridging is a powerful mechanism for merging identities from different security domains and breaking down identity silos. During identity bridging, the requestor domain is responsible for authenticating, while authorization is handled by the provider domain hosting the web service or it is entrusted at the source. In a mergers and acquisitions scenario, for example, Enterprise A merges with Enterprise B. Each enterprise has its own identity provider, but would like to share identities with minimum resources and no interruption to their existing security architectures. Using
API Gateway
products, identity bridging is configured between Enterprise A and Enterprise B using one of two credential source types: a SAML (Security Assertion Markup Language) token or an X.509 certificate.
For brevity, the generic "Trusted Authority" and "Federated Gateway" references are used in all identity bridging examples, workflows, and instructions. The Trusted Authority is the certificate authority (CA) that issues and manages security credentials and is responsible for authentication. The Federated Gateway is the web service provider that is responsible for authorization. The words "trusted" and "federated" are used from the point of view of the service requestor.
Identity Bridging Using the SAML Credential Source
image2014-10-20 9:12:29.png
A description of the data flow:
  • Trust is established at design time. A Federated Identity Provider is mapped to the trust certificate.
  • At design time, the Federated Gateway policy is configured with constraints requiring a SAML token signed by the Federated Identity Provider authority.
  • At run time, the client requests a signed SAML token from the Security Token Service and then attaches it to the message as the SAML token profile. The
    API Gateway
    confirms the signature and routes the message.
Identity Bridging Using the X.509 Certificate Credential Source
image2014-10-20 9:14:24.png
A description of the data flow:
  • Trust is established at design time; a Federated Identity Provider is created.
  • A Federated Gateway policy contains a SSL CMA or WS Signature.
Identity Bridging with CA API Management Products
API Gateway
The required provider-side
API Gateway
, known as the "Federated Gateway" is used for authorization in an identity bridging configuration. The Federated Gateway establishes a certificate-based trust relationship with the authentication source by importing trusted certificates into its trust store. The authentication source can be any certificate authority (CA) or another
API Gateway
 that acts as a CA*.
API Gateway
acting as a certificate authority is available only for
API Gateway
 - XML VPN Client use cases.
The Federated Gateway uses three types of federated identities for mediating requestor credentials: federated users, federated groups, and virtual groups. It delegates authentication to one or more Trusted Authorities while preserving authorization for the Federated Gateway.
Any of the
API Gateway
products can be used for identity bridging. When SAML is used as a credential source in an identity bridging configuration, the authentication source must be able to issue a SAML token. If another
API Gateway
is used as the credential source, then it is already able to issue a SAML token. See "Workflow Using SAML."
API Gateway
 - XML VPN Client
The requestor-side
API Gateway
 - XML VPN Client is responsible for decorating request messages based on the web service policy assertions defined in the Federated Gateway. Decorated messages are sent from the
API Gateway
 - XML VPN Client to the Federated Gateway for web service authorization. If a policy contains a Require SAML Token Profile assertion, then part of the client’s decorating task may involve getting a SAML token from the Trusted Authority during the initial connection or if the original SAML token has expired.
API Gateway
- Policy Manager
The Policy Manager provides the interface for importing trusted certificates (CA certificates and/or server certificates extracted from the Trusted Authority) into the Federated Gateway trust store. The Policy Manager also provides the interface to configure and manage one or more Federated Identity Providers (FIPs), link trust store certificate(s) to FIPs, and configure the Federated Gateway SAML policy.
Using the CA API Gateway - XML VPN Client for Identity Bridging
In an identity bridging configuration, the CA API Gateway - XML VPN Client can be used to delegate authentication to the Trusted Authority, while preserving authorization for the Federated Gateway hosting the web service.
The CA API Gateway - XML VPN Client interfaces with the requestor’s SAML or X.509 certificate authorization source that validates an authentication. Once the CA API Gateway - XML VPN Client receives the authentication assertion or token, it embeds this evidence and then signs the SOAP message. The Federated Gateway then uses this evidence to securely authorize access to the protected web service.