You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by ar...@cornell.edu on 2002/09/03 17:33:38 UTC

Custom security

Hello all,

  I have just begun digging into Axis to see if it is feasible to 
implement transparent Kerberos security.  It appears as if I can register 
handlers to append credentials after a call is invoked on the client, and 
authenticate credentials before the call is invoked on the server.  
However, there seem to be many places in which to register handlers (and 
in fact the Axis engines themselves are handlers!), and I am not sure 
where to start.  I have looked at the examples and understand how the 
WSDD config document is loaded, but I would rather make this as 
transparent to the developer as possible, and manually register handlers in 
special subclasses (instead of forcing the use of arbitrary XML 
configuration files or strings)...unfortunately I don't see where the WSDD 
config is sticking the handlers it reads out of the file.  There seem to be 
two places to register handlers on the client:  1) Through overriding (I can 
see no other way) the AxisEngine to return your handlers in getGlobalRequest 
and getGlobalResponse methods 2) through calling getHandlerRegistry on the 
Service object...however this API only gets/sets a list of HandlerInfoS, so 
I'm not sure where to actually stick the handler.

The second requirement I have is to be able to encrypt the SOAP request.  
The best bet looks to me to subclass the Message object which the Call 
sticks in the MessageContext, and override the 'writeTo' method, and 
simply write the encrypted bytes.  This is called by HTTPSender.  However 
I see no HTTPReceiver analogue on the server side, by which I can 
transparently decrypt the contents of the message before it is interpreted.

Any advice?

Aaron Hamid
CIT/I&D
Cornell University

Flow:

* client creates KerberizedService (** client handler is registered?? **)
* client gets KerberizedCall through createCall
  KerberizedCall overrides setRequestMessage() to use Message subclass 
which encrypts upon writeTo
* somehow add credentials to message context/headers
* HTTPSender sends request and contents are encrypted from writeTo

* server receives request, authenticates credentials in headers, and 
decrypts body (** authentication must occur before decryption... 
apparently no hook prior to XML parsing?? **)
* encryption key is stashed (probably in MessageContext)
* reverse process ensues to encrypt the contents again on the way out

* client receives response and decrypts it