I was recently asked to help one of our customers design a solution for an interesting use case. Since it may well be relevant for others, I thought I would share it.

The use case

The customer currently has an internal, employee custom application, which is integrated with an external SAML-based Identity Provider (IdP) for the purposes of single sign-on (SSO). They have also adopted Oracle Enterprise Resource Planning (ERP) SaaS, which is part of our Oracle Fusion portfolio. The custom application needs to talk to Fusion via its REST APIs. However, the application needs to make API calls in the context of the end-user and not a generic service account. By providing the user’s identity, the SaaS application can enforce its security model, helping to ensure that the user can only perform operations that they are authorised for, and only on authorized data. We can sum up the requirement in the following diagram:

The challenge

Oracle Fusion supports two methods of authentication for its REST API: Basic and OAuth. Since the end-user is authenticating to an external provider, the custom application doesn’t have the user’s credentials, meaning Basic authentication is not appropriate. We certainly don’t want to have to ask the user for their SaaS credentials as that would be a very poor user experience! So, we look at OAuth authentication. However, the custom application only has a SAML token from the IdP. This can’t be used to authenticate to the SaaS API.

Another point to consider is that the customer can’t make significant changes to the custom application. Therefore, anything we did had to be external to that application.

The solution

Fortunately, we have the services needed in Oracle Cloud Infrastructure (OCI) to provide a solution to meet this requirement. The diagram below summarizes the solution that was proposed. This was based on existing work done here and here.

The proposed solution enables the existing IdP SAML token to be consumed and validated, before being exchanged for a token that can be trusted and consumed by Oracle Fusion. The key point within this solution is that the identity of the end user from the custom application is being propagated all the way to Oracle Fusion using pre-configured trust relationships, enabling the solution to use trusted tokens with validated signatures, to accept the asserted identity from the previous layer before issuing a new token that is acceptable to the next layer. This not only helps to ensure that the identity can be audited and logged at each stage of the flow, but that Fusion can apply its user access controls based on the user making the call. These include security capabilities such as role-based access control (RBAC) and data security controls. Each component in the solution serves a specific purpose.

OCI API Gateway intercepts the API request to enable the token exchange.

OCI Functions validates the existing IdP SAML token before requesting a token that can be consumed by Fusion.

OCI Vault securely stores the cryptographic material used by the OCI Functions service.

OCI Identity and Access Management (IAM) is the central point of identity trust across the Oracle components.

The solution provides the overall goal of being able to propagate the user’s identity from the custom application to Fusion, using a central point of trust, and a token that is supported by Fusion.

The technical bit

Let’s dive into the details of how this was built. The detailed flow below shows the exchange of tokens within the solution.

  1. The IdP SAML token is passed to the API Gateway within a header of the REST request made by the custom application.
  2. API Gateway intercepts the request and calls a custom authorizer, which is implemented as an OCI Function (Fn). The purpose of the Function is to validate the external IdP SAML token. The Function will check:
          a. The validity of the digital signature. The function is configured to trust the signature of the external identity provider.
          b. The timestamp validity
    It will also check that the Audience and Restriction values within the SAML token match pre-configured values. Note that these values will match the custom application and not the API Gateway, so will be a static check within the function.
  3. Once validated, the Function generates a local JSON Web Token (JWT) containing the user identifier it extracts from the SAML token. The Function will retrieve the private signing key from OCI Vault and digitally sign the JWT token.
  4. The Function invokes OCI IAM and requests a JWT token for Oracle Fusion. It uses its local JWT token as the grant type and requests a scope for Oracle Fusion.

    Note that, we can’t just pass the SAML token to OCI IAM since it wasn’t issued for OCI IAM by the external IdP and would therefore fail validation.
     
  5. OCI IAM has been configured to trust the Function by importing the public key matching the signing key. OCI IAM will then validate the Fn JWT token, i.e.:
          a. Digital signature
          b. Issuer
          c. Audience
          d. Scope
  6. If the token passes the validation checks, OCI IAM will issue a new JWT token scoped for Oracle Fusion (assuming its policy allows it to). The token will be returned to the Function.
  7. The Function returns the OCI IAM JWT token to API Gateway, which injects it as a Bearer token in the Authorization header and makes the request to Oracle Fusion.
  8. As part of the central trust, Oracle Fusion has been configured to trust tokens issued by OCI IAM. The SaaS platform will validate the OCI IAM token and extract the user identifier before servicing the request and returning the appropriate status code and payload.

Extending the use case

The customer was happy with the flow, but then introduced an additional requirement. They also wanted to be able to abstract the SaaS API so that they could consolidate several API calls and enrich the data that was been returned to the custom application. On top of that, they are planning on integrating other applications with this platform and therefore wanted the flexibility to be able to transform the messages if required. They requested a pattern to enable this.

Fortunately, it is easily achievable by extending the proposed solution to include an enterprise integration layer, Oracle Integration Cloud.

The only difference between the initial solution and this extended solution is the additional token exchange that is required to ensure the identity is propagated to every layer. The core principle of OCI IAM being set up to trust the custom Function still applies. Whether a single Function is used, or two separate Functions (as shown below) is down to an implementation choice.

In summary, we were able to provide a solution to meet this customer’s requirements, without the need for any changes to their custom application. We took advantage of the breadth of the Oracle cloud portfolio, including SaaS, integration, functions, and security, all working together to deliver the solution.

I hope you found this article useful. Don’t forget you can try OCI for free at https://www.oracle.com/cloud/free/#free-cloud-trial, where not only will you have free credits to try services such as those in this article, but you will also be given access to a range of always-free services, which you can continue to use beyond your trial.

To learn more, visit the Oracle Identity homepage, or you can also find out more about Oracle Cloud Applications Security here.