Need to finalize design for Authentication when 3rd party services connect to OSDU deployed for operator
Context: Operator X has a OSDU operational environment in their CSP provided tenant/subscription - imagine a Azure subscription for example.
Challenge: Operator X wants to subscribe to two SaaS solutions A and B and wants to make sure these SaaS solutions can access data in their managed OSDU instance. How can these solutions A and B provide JWT tokens that is acceptable to the OSDU instance and in particular when OSDU aims to return blob streams from underlying CSP which require a operator X tenant specific authentication token (and audience)
Details: SaaS solutions need to authenticate customer users against multiple IdPs and to ensure their micro-services are abstracted from this plethora of authentication IdPs, typically use a pattern of an shadow identity or a SaaS specific internal identity token (JWT for simplicity). However when these services need to access the OSDU layer and these expect a CSP issued JWT token, retrieving this will be a challenge for the SaaS solutions.
Adopting a similar shadow account approach may also be a problem from scaling perspective if the operator X needs to create a shadow account per user per SaaS service that will connect to OSDU -- O(n2) cardinality.
Further if operator X's primary IdP happens to be a CSP agnostic source such as PingIdentity or Okta etc., then the authentication token received by SaaS solution A or B will not be compatible with OSDU or more importantly for OSDU services to return back resources such as a blob URL that requires a CSP specific authentication token. In this example operator X user Jack has logged in to SaaS A by redirection to PingIdentity - Jack's JWT is accepted by SaaS A to initiate the service and irrespective of whether SaaS A has its own shadow/wrapped identity, the best it can echo back to OSDU layer is Jack's JWT from Ping and not from Azure AAD which is what operator X's OSDU deployment depends on.
This poses a deployment/integration challenge from an openness perspective and we need a scalable way to resolve this problem in R3. Please prioritize and propose solution in reference URL below.