Constrain access to a fhir store resources through a Proxy (smart on fhir?)

[bmcd77]

I have a GCP Healthcare API deployed in GCP. I have an API Product & proxy returning data ok. The IAM service account in the Apigee project has firestore reader permissions in the fhir store project and to access the fhir store my proxy is reading the fhir store like this :

  <HTTPTargetConnection>
    <URL>https://SET_URL_FROM_CONFIG</URL>
    <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
  </HTTPTargetConnection>

The above works just fine.

I'm looking to create an API Product that constrains access to a subset of fhir resources. e.g. Organization, Location, Practitioner

What are my options?

What I've tried:

1. Using Operations --> No good. I can constrain the proxy by Operations e.g. /Practitioner/** but this is easily circumvented with a fhir reverse include query like this :
proxyname/Practitioner?_id=<unique_fhirstore_id>&_revinclude=Encounter:practitioner

2. Was hoping using scopes like this below would work? docs ref
See the various attempts commented out..

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage continueOnError="false" enabled="true" name="AssignMessage-AddScopesHeader">
    <DisplayName>AssignMessage-AddScopesHeader</DisplayName>
    <Properties/>
    <Add>
        <!-- https://cloud.google.com/healthcare-api/docs/smart-on-fhir#set-and -->
        <!-- This is a scopes test. Will this restrict the FHIR server as described ?? -->
        <Headers>
            <!-- <Header name="X-Authorization-Scope">user/Practitioner.read user/PractitionerRole.read user/Organization.read user/Location.read</Header> -->
            <!-- <Header name="X-Authorization-Scope">user/Practitioner.read</Header> -->
            <!-- <Header name="X-Authorization-Scope">user/*.rs</Header> -->
            <Header name="X-Authorization-Scope">user/*.read</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

It's not behaving at the moment. Still trying it. Thought I'd ask if in case I was heading down a rabbit hole!

Thanks

[dchiesa1 · Accepted solution]

What you're doing makes sense to me.

Injecting headers like the X-Authorization-Scope to communicate to Cloud Healthcare API what access control is necessary, is an exemplary use of Apigee in front of FHIRStore.

If I were you, I would make a couple changes:

1. use Set instead of Add. Set overwrites any existing header, which is what you want here. Add will ... add to any existing header, or set the header if it is not already present. By using Set, you insure that the header holds only the value your proxy intends to be there. You don't want the client to be able to send in a X-Authorization-Scope header, and then have Apigee simply add to it. This would be a security vulnerability, obviously.

2. Omit the

    <AssignTo createNew="false" transport="http" type="request"/>

   It does nothing. You DO have to make sure you attach that AssignMessage policy into the Request flow, in order for it to be received by the Healthcare API.

[dchiesa1 · Accepted solution]

I was trying to avoid adding a call to an Authorisation server (to turn a JWT with scopes into an access token as you've done here in github) between Apigee and the Healthcare API.

YES. And the Authentication element.... this one:

     <HTTPTargetConnection>
        <URL>https://SET_URL_FROM_CONFIG</URL>
        <Authentication>
            <GoogleIDToken>
                <Audience useTargetUrl="true"/>
            </GoogleIDToken>
        </Authentication>
        ...

Does that for you.

OR DOES IT?

You specifically wrote

...turn a JWT with scopes into an access token between Apigee and the Healthcare API.

I want to call your attention to the options under the Authentication element. With the child element, you can tell Apigee to either send an ID TOKEN or an ACCESS TOKEN in the Authorization header. With the configuration shown above, using GoogleIDToken, it sends an ID TOKEN. I think what you want is an ACCESS TOKEN, so you must use GoogleAccessToken in the configuration. Like this:

     <HTTPTargetConnection>
        <URL>https://SET_URL_FROM_CONFIG</URL>
        <Authentication>
          <GoogleAccessToken>
            <Scopes>
              <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
            </Scopes>
          </GoogleAccessToken>
        </Authentication>
        ...