We’re trying to set up a reverse invoke deployment involving an API Gateway server and a IS, where the authentication method to IS server is with Client Certificates.
All ports are set up with Request Client Certificates authentication option.
IS internal port is successfully connected to API Gateway registration port, but when invoking the API, destination IS is not using the keystore certificate to authenticate. The API Gateway is using Default user.
Some of testing I’ve made:
Direct invocation to the API Gateway with same SSL settings (same keystore) → works fine
Adding a Username and Password to the Outbound Authentication - Transport policy → makes the request work fine. There is no option of SSL authentication on this policy.
Adding Default user to allowed ACL → makes the request work fine.
Is there any known limitation to use SSL Authentication with reverse invoke? Am I doing something wrong?
You might want to add the client certificate mapping for the Default User on the internal IS under Security → Certificates.
See IS Administrators Guide for details.
The problem is that “Default” user shouldn’t be used since this is not a real user and it is defined for anonymous request (with an anonymous ACL restricted to avoid unauthenticated requests).
I think there should be a way to define the user that tries to connect from API Gateway, just the way is done when user/password is defined.
For direct invoke this is done properly (we define it in Endpoint Alias), but doing the same on reverse invoke setup does not work.
the connector ports on the EnterpriseGateway itself need to be set to “Request Client Cert” or “Require Client Cert”.
No external user needs to be defined here.
On the internal IS you need to define a user for this interface and assign this user to the ACL protecting the API Webservice.
Add this ACL to the port to enable the service on this port.
Request the client certificate from your partner and add a mapping for this cert and your API interface user in internal IS.
We are using similar scenario in our RosettaNet/TradingNetworks interface.
