As I understand it, clients that enter through a proxy port on the Integration server (setup up in reverse invoke mode) are authenticated by the internal server.

This works correctly for us only if the clients are defined within the internal server. Clients that we have defined in the LDAP receive a “Invalid credentials” message going through the proxy port, even though they can sign in when they connect directly to the internal server.

I’m not sure what the problem is. It seems that when a client goes through the proxy port, the pluggable module (that provides the LDAP authentication) is bypassed.

Has anyone encountered this problem? Or solved it!?

You hit the nail on the head when you said “…clients that enter through a proxy port on the Integration server (setup up in reverse invoke mode) are authenticated by the internal server.”

Users (clients) must be defined on the internal server, and need not be defined on the RI server. Any local user definitions, LDAP users, or pluggable authentication modules are ignored on the Reverse Inovke server (for the port(s) that are configured as reverse invoke ports).

I’m don’t understand what you mean by “Clients that we have defined in the LDAP receive a ‘Invalid credentials’ message going through the proxy port, even though they can sign in when they connect directly to the internal server.” Where is this LDAP connected? Is it connected to the Reverse Invoke server or the internal server?

Is it possible that you have the port on the Reverse Invoke server configured to “require certificates”? Or if it’s an SSL port but not requiring certificates, perhaps the server’s certificate isn’t signed by a CA recognized by the client? What happens when you use a browser to connect to the RI port? Do you get a certificate error?

Just some ideas… not clear enough what the problem is to know for sure what the solution will be!

I guess I didn’t define my problem clearly enough. All clients are define on the internal server. Some directly in the internal server and some in a LDAP that is connected to the internal server.

My problem is that only those clients that are defined directly on the internal server are able to connect through the proxy port. Clients that are defined in the LDAP can only connect directly to the internal server. If the LDAP defined clients try to connect through the proxy port on the reverse invoke server they are rejected.

And That’s in conformance to what is expected to happen.

In order for clients defined in LDAP to be able to connect thru proxy port on RI, you need to write a custom LDAP authentication module.

On advantage site under Bookself, please look for Building_Custom_Authentication_Modules.pdf

This will guide you through this process.

HTH,
Saurabh Maheshwari
(sm195@lucent.com)

This was done. Describing this problem in more technical terms, the problem it seems is that when a client connects through the proxy port, the authentication factory is bypassed or ignored.

If that is the case, i will suggest you look through your code more throughly. According to me bypassing custom authentication module will happen only if standard passes. Also look how your servers are set.

And please understand this Authentication flow copied from Building_Custom_Authentication_Modules.pdf

—>
B2B Server processes authentication tokens as follows:

1. B2B server receives a service request from a client. IP address checks
   are performed. If they pass, proceed to step 2.
2. B2B server attempts to use the standard authentication module 2 . If it is
   successful, skip to step 4.
3. If a custom module is installed, it is called with the authentication token
   passed by the client (either a BasicToken or X509Token). The custom
   module processes the token and proceeds to step 4.
4. If the authentication module determines the authentication token is
   valid, it returns the userid (a String) and proceeds to step 5. If not, a
   null String is returned. If this was an X509 module and certificates were
   requested but not required, return to step 2 to attempt to use Basic
   authentication. Otherwise, fail the request.
5. If the module returns a userid, the B2B server looks up the userid in
   local user database or in LDAP/NIS to determine group membership. If
   the group is in the service�s ACL, then it is allowed to run.

<--------

HTH,
Saurabh.

I think there is a bug in the way authentication works through the reverse invoke. I placed a trace in the pluggable module. It does get there and it does return a user name. Yet when a client comes through the proxy port he is denied access and when coming directly into the internal server he is allow.

Is this issue happening only with SSL based authentication? If yes, with require turned on?

I will again suggest you to look at your code. I somehow feel, it is admin type issue in the way your servers are setup rather then it being a webMethods bug.

as per Step 5 of the guide:
5. If the module returns a userid, the B2B server looks up the userid in local user database or in LDAP/NIS to determine group membership. If the group is in the service�s ACL, then it is allowed to run.

so if you say, the pluggable module is returning a user, please check to see if that user is defined in the local user database !! Providing additional details in your posts will certainly help !

Have you contacted wm-support about this “bug” that you see? What did they have to say on it??

Sincerely,
Saurabh.