Grant access to a particular flow for a particular username only when API proxy is a passthrough

[adamsanchez]

Looking for some guidance here.

I have a particular API and proxy which is a passthrough using username and api_key as a parameter in the Curl without any Apigee Auth involved.

There is a particular flow (endpoint) which we want only to be accessed by a particular username so was wondering whats the recommeded way here others would do this? Eg by a raisefault policy?

The particular flow (endpoint) would only ever be used by a select username or if anything maybe a couple more but at the moment its only available to one username and want to restrict that flow to that specific user only.

This particular backend service cannot control this as its an all or nothing via this particular API so want the Apigee proxy to stop access to that particular flow for anyone other that the specific username.

[dchiesa1 · Accepted solution]

Yes, you can do that with RaiseFault. Wrapped in a condition, in the flow.

    <Flows>
        <Flow name="employees">
            <Description/>
            <Request>
                <Step>
                    <Name>RF-UnknownRequest</Name>
                    <Condition>request.header.username != "admin"</Condition>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/employees") and (request.verb = "GET")</Condition>
        </Flow>
        <Flow name="employee">
            <Request/>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/employee/*") and (request.verb = "GET")</Condition>
        </Flow>
        <Flow name="Unknown">
            <Request>
                <Step>
                    <Name>RF-UnknownRequest</Name>
                </Step>
            </Request>
            <Response/>
        </Flow>
    </Flows>
  

see attached

username-authz-rev1-2019-03-21.zip

$ curl -i https://$ORG-$ENV.apigee.net/username-authz/employee/80057
HTTP/1.1 200 OK
Date: Thu, 21 Mar 2019 17:34:25 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked

{"id":"80057","employee_name":"dsfgdg","employee_salary":"0","employee_age":"1","profile_image":""}


$ curl -i https://$ORG-$ENV.apigee.net/username-authz/employees
HTTP/1.1 404 Not Found
Date: Thu, 21 Mar 2019 17:34:33 GMT
Content-Type: text/plain
Content-Length: 9


Not Found


$ curl -i https://$ORG-$ENV.apigee.net/username-authz/employees -H username:admin
HTTP/1.1 200 OK 

...

Having said that, I don't think it's a grand idea.

That you CAN do something, doesn't imply that it's a good idea.

It would be much better if you used an OAuth token, and associated a username to the token. (Either via authorization code grant, or via password grant).

Then you would use VerifyAccesstoken in the flow, and after that, you could do... basically the same thing, except rather than testing the username passed in the header , you would examine/test the username attribute on the token. Or even better, a group or role name that was asserted by the Identity Provider, and then attached to the token at the time of token issuance.

But implementing it this way, the "better" way, would require you to have an authentication system, something like Google Signin, ActiveDirectory or Okta or Auth0, etc, that could authenticate users and provide tokens that identify those users.

[adamsanchez]

Thank you very much @Dino-at-Google as yes completely agree about it being managed a better way and it is something we will be looking to accomplish at some point with 'Auth' but at the moment as its a passthrough proxy and only one user ever going to use that specifc flow (endpoint) then we can manage it this way for the meantime i suppose.

[dchiesa1]

What kind of Suzuki do you ride?

[adamsanchez]

I have a 2006 GSXR 750 which has never ever let me down and one of the most comfiest and loveliest sports bikes still to this day imo but also have a KTM 1290 Super Duke R for that extra BHP 😉