Bypass credentials via SOAP proxy

Not applicable

Hey,

I am trying to build an API proxy (REST - SOAP - REST) on top of Informatica MDM SIF web services.

https://kb.informatica.com/proddocs/Product%20Documentation/4/MDM_901_DB2_SIF_Guide.pdf

The proxy itself is generated quite fine, but when it comes to security model, I want to have one layer on Apigee side (OAuth2.0 client credentials), and at the same time align particular API client to actual underlying SIF account.

I mean, Informatica MDM Hub has own User Access Management system and you can create new accounts/permissions there. As a result, you need to bypass username/password as a request payload. So, the idea is don't hardcode it in PROXY, but instead keep as a variable in Apigee and attach via Policy (?) based on the API client.

<urn:searchQuery>

<!--Optional:-->

<urn:username>test</urn:username>

<!--Optional:-->

<urn:password>

<urn:password>mypass</urn:password>

<urn:encrypted>false</urn:encrypted>

</urn:password>

So, do you have any best practices/guidelines how to achieve this scenario and ensure this bypassing model?

Thank you!

0 4 948
4 REPLIES 4

Hi @Dzmitry T.

There can be multiple ways to do this depending on the requirement/design

1. if username/password is same for every API call. I will recommend to them in an encrypted kvm, extract it from there in the target request postflow and assign it to your request payload using the Assign Message policy.

2. If you want to associate username/password with apikey. Then it can be stored as custom attributes in the developer app retrieved from the developer app flow variable (populated after execution of verify apikey or oauth v2 verify token policies). it can be extracted and assigned in the same manner as point 1.

3. If username/password is required to be passed as input in every api call then it can be passed as Basic Authentication credentials in the Authorization parameter, if it is not being used to pass APIGEE credentials/token etc. In case Authorization is already in use, pass username/password as a base64 encoded concatenated string in a custom header parameter. The value can be extracted and decoded using the Basic Authentication policy

Hope this answers your question.

Thanks a lot for such quick turnaround.

With regards to options, I like all of them 🙂

But, I'd agree, that it depends on the scenario and having choice is really great.

As for now, option #1 looks like a short term solution for my need.

BTW, I checked KVM (I have no experience with it) and seems that it's not available in Sandbox environment, so probably this is the specific of this type of env.

Thanks again.

KVM is available in the free org inside Environments menu

5321-capture.jpg