Applications which are exposed as web services need high level security procedures. “Identity silos” – a stand-alone identity store which possess access control rights and privileges of identities are creating serious problems when an applications are willing to integrate to multiple applications in different domains. Hence Identity Bridging overcomes the issues created when using Identity silos by using its credential source types. Identity Bridging plays an important role in making the web services to interact between themselves with the help of authentication and authorization techniques from different web services.
How Does Identity Bridging Works ?
Identity Bridging acts in such a way that the requestor domain (Trusted Authority) is responsible for authentication while provider domain responsible for authorization (Federated Gateway) hosting the web service or it is assigned at the source.
Types of Identity Bridging:
Identity bridging can be configured by either of the following credential source types.
- SAML (Security Assertion Markup Language) token.
- X.509 certificate.
With this method, Trust is established by mapping the Federated Identity Provider(FIP) to the trust certificate. The provider domain is configured in such a way that it requires SAML token signed by FIP. During the run time, the requestor domain asks for a signed SAML token from the FIP and attaches the same to the message as SAML token profile. The CA API Gateway, after the successful authentication of the signature, sends the request data to the provider domain and hence the connection between the requestor and provider is established using SAML token.
X.509 is an important standard to manage digital certificates and public key encryption. By using this method, trust is established by creating a FIP. And in turn, FIP will require the certificates like SSL CMA or WS Signature from Federated Gateway trust store which is the repository/database for the certificates from other security domains. There are 3 scenarios for authentication and authorization by using X.509 certificate.
- CA Certificate Only – The certificates of requestors are imported directly to the Federated Gateway Trust Store at once so that whenever requestor domain sends a request, FIP with the current certificate tries to match it with the certificates that are present in the trust store and establish connection to the provider if it succeeds with the authorization.
- Individual Client Certificates Only – Whenever a client certificate is imported, the credentials of the client will be compared against the already stored client certificate. FIP doesn’t have a role in this case. Any mismatches will lead the authorization to fail and the connection will not be established between the web services.
- Both CA Certificate and Individual Client Certificates – With this option, both the above mentioned scenarios can be handled.