Changing client principal in the gatekeeper leads to MARSHAL errors

From Support
Jump to: navigation, search

Question:

Attempts to modify the principal of a request sent through the gatekeeper IIOP proxy object using an interceptor lead to MARSHAL errors on the server.

It may be desirable in some situations to modify the principal in such a way that the server can detect that the client request is being received via an IIOP proxy rather than directly from the client.

Is there a way to modify the principal data in a request that is passed through the gatekeeper to the server without introducing alignment errors in tehg request data?
It is very important that HP-UX users install all recommended patches from HP and follow the kernel tuning instructions carefully. Here is the information as of 5/3/99.

Answer:

The current gatekeeper is written to preserve client principal data. The
code as written makes the assumption that the principal data will not be
changed.  Changing the principal data length in any way causes the
alignment in the request to be incorrect. This problem should go away
when the firewall RFP support is added in VBJ 4.0.

Currently the only way to avoid this problem is to do one of the
following:

- Set the principal in a prepare_request client interceptor and pad the
new principal based upon the length of the client principal in order to
preserve the alignment.  Here is an example:

    public void prepare_request(RequestHeaderHolder hdr, Closure
closure)
    {
      String dn = "CN=test4, o=GTE, c=US"; // for example
      byte[] principal = dn.getBytes();
 
      int       length_old = (hdr.value.requesting_principal != null) ?
                hdr.value.requesting_principal.length : 0;
      int       length_new = principal.length;
      int pad = (length_old <= length_new) ?
                (16 - (length_new - length_old) % 16) :
                (length_old - length_new) % 16;

      if (pad != 0)
      {
        byte[] padded = new byte[principal.length + pad];
        System.arraycopy(principal, 0, padded, 0, principal.length);
        for (int j = principal.length; j < padded.length; j++)
             padded[j] = (byte)0;
        principal = padded;
      }

      hdr.value.requesting_principal = principal;

      print("prepare_request");
    }

If this client interceptor is installed in the gatekeeper, it will
replace the principal in the request being sent to the server. The above uses an
arbitrary string in the above, but  the algorithm will
work with an arbitrary byte array as long as the length of original and
new principal is known.

- A second alternative is to send the information from the gatekeeper to
the server using a service context in the request header.  This may be a
better long term approach as principal is deprecated from later versions
of the CORBA spec. A send_request interceptor installed in the
gatekeeper can supply the service context.  A receive_request
interceptor in the server can extract and examine the service context
data.  In this scenario any original client principal data also goes
through the server (although it can also be replaced by filler as
described above in the prepare_request interceptor). The developers have
advisedthat this approach may require adjusting the alignment also.

A stand alone example to manipulate the service context of the request
is available at the following location for your reference:

        ftp://ftp4.inprise.com/private/ts/examples/servicecontext.tar



Article originally contributed by