IBM Security Verify

 View Only

ISAV - custom Authorization server, OIDC/OAUTH scopes

  • 1.  ISAV - custom Authorization server, OIDC/OAUTH scopes

    Posted Fri November 18, 2022 09:56 AM
    We are currently using On-prem ISIM10 and ISAM10 for 5 of the US state government projects providing SSO to Target applications.

    We have a new requirement to integrate a new application, which is a FHIR (Fast Health Interoperability Resources) application hosted on AWS.
    We need to integrate this application using OIDC.

    We are considering to move to IBM Security Verify (SaaS) for all our current applications and new application integration as well.

    We have done a POC using Okta for integrating the above mentioned FHIR application which is working.

    For us to consider moving to IBM Security Verify (SaaS) we need to understand some functionalities for this FHIR integration, IBM can provide.

    The integration flow works like this,

    1. AWS FHIR API has SMART configuration and Metadata end points, which internally call our IBM Security Verify Authorization Server.
    2. The request will come from a third party app to AWS proxy, AWS Proxy Will cache the request and then makes an OIDC call to a custom Application.
    3. This custom application which will show the consent screen, based on the consent the original request will be reinitiated to IBM Verify Authorization Server.
    4. The Authorization server should generate Access Token after making an external API call to AWS (lambda function present within AWS Proxy) server to verify the consent.
    5. The user entry will be present in IBM Verify, however, there exists a Uid (not stored in our database) for accessing the data which will only be fetched by making a call to the AWS API endpoint before the Access Token Generation. This Uid has to be collected and inserted into the Access Token and the flow continues (to AWS proxy and then to Third party App)

    We understand that AWS Proxy should be configured to make a call to our IBM Verify Authorization server endpoints for the above flow .

    We need some confirmation if we can achieve the following using IBM Verify (SaaS) with respect to the flow,

    -Create custom Authorization server and define Application supported scopes and Claims (with or without mapping rules) {Supported by Okta}
    -Custom consent app should be able to make a call to IBM Verify Authorization server to check scope and client ID. {Supported by Okta by creating an Okta API token}
    -Make external API call to validate the consent and insert the Uid to Access Token at runtime / dynamic.

    References : fhir-works-on-aws/

    Dhanasekaran S