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
Layer7 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
    Layer7 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 Layer7 API Management Products
Layer7 API Gateway
The required provider-side
Layer7 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).
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
Layer7 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
Layer7 API Gateway
is used as the credential source, then it is already able to issue a SAML token. See "Workflow Using SAML."
Layer7 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.