Hi Ali, The secUtil.jar is specific to the security sample and it contains the - callback handler class - crypto properties file - key store
These are used by the client and it it included with the other jars required by the client (The client class is also in the secUtil.jar for this purpose). Coincidentally it is be the same configuration for the service as well... therefore in the case of the axis2 security sample there was no harm in having the secUtil.jar in the tomcat's lib dir. But as you pointed out we can surely improve the statement in the README.txt of the security sample as follows: 'Copy all jars except the secUtil.jar in the samples/security/lib directory to axis2/WEB-INF/lib/" Therefore if you are trying your own scenario you will _not_ need the secUtil.jar and you can package the above mentioned config information in the service archive (.aar file) Thanks, Ruchith On 3/29/06, Ali Sadik Kumlali <[EMAIL PROTECTED]> wrote: > Hi Ruchith, > > Please don't respond my previous questions ;-) I've just found a great > source that clearly tells about Axis's security configurations: > http://blogs.cocoondev.org/dims/wss4j/compare.htm > > I applied Scenario B to Axis2 and it worked. But there was still something > confusing. Then I figured out that secUtil.jar was under Tomcat's lib folder > and the same files were under SecureService.aar which resided in > WEB-INF\services folder. After I'd removed secUtil.jar from Tomcat's lib, > everything went in a understandable way. > > Consequently, there seems something wrong in README.txt of security sample: > "4.) Copy all jars in the samples/security/lib directory to > axis2/WEB-INF/lib/" > > One of the jars in samples/security/lib folder is secUtil.jar > > Hope I don't miss something ;-) > > > > Ali Sadik Kumlali <[EMAIL PROTECTED]> wrote: > Hi Ruchith, > > > First of all, I'm sorry for this long message :( But, Axis2's site has > limited information about security configuration(I think, at least ;-) and > actually couldn't find a good resource on the Web. > > After I had finally managed to run securitySample, gave a try to my scenario > by changing configuration of the sample. There are strange(?) cases I cannot > understand. > > Here are my definitions: > > Client Side - axis2.xml > <parameter name="OutflowSecurity"> > <action> > <items>Signature</items> > <user>alice</user> > > <passwordCallbackClass>sample.security.PWCallback</passwordCallbackClass> > <signaturePropFile>sec.properties</signaturePropFile> > > <signatureKeyIdentifier>SKIKeyIdentifier</signatureKeyIdentifier> > > <signatureParts>{Element}{http://www.w3.org/2005/08/addressing}To;{Element}{http://www.w3.org/2005/08/addressing}ReplyTo;{Element}{http://www.w3.org/2005/08/addressing}MessageID</signatureParts> > </action> > </parameter> > <parameter name="InflowSecurity"> > <action> > <items>Signature</items> > <signaturePropFile>sec.properties</signaturePropFile> > </action> > </parameter> > > Server Side - services.xml > <parameter name="InflowSecurity"> > <action> > <items>Signature</items> > <signaturePropFile>sec.properties</signaturePropFile> > </action> > </parameter> > > <parameter name="OutflowSecurity"> > <action> > <items>Signature</items> > <user>bob</user> > > <passwordCallbackClass>sample.security.PWCallback</passwordCallbackClass> > <signaturePropFile>sec.properties</signaturePropFile> > > <signatureKeyIdentifier>SKIKeyIdentifier</signatureKeyIdentifier> > </action> > </parameter> > > H ere are my questions: > > 1) Is this configuration enough, if I only need signing? > > 2) Is it secure enough to sign only WS-Addressing related parts as shown in > signatureParts? If doesn't, what can I do in the case of all my message > bodies have their own namespace and do not follow a pattern? > > 3) Does client send messages by signing with its private or public key? > > 4) Client sends messages by signing with its key according to the rules > defined in OutflowSecurity of axis2.xml. Server accepts the message > according to the rules defined in InflowSecurity of services.xml. But, when > server sends response back to client, it doesn't use OutflowSecurity of > services.xml. I commented out OutflowSecurity definition of services.xml and > retrived the message at client endpoint successfully. Is this the expected > behaviour? If it is, when the server uses its OutflowSecurity? > > 5) If server doesn't use OutflowSecurity for the response messages; > - How does it sign the message? > - Which certificate does it sign with? > - Which certificate does the client uses to validate the response message? > And how can it decide? > > 6) What does <items>Signature NoSerialization</items> mean? > > Thanks in advance, > > Ali Sadik Kumlali > > Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > Hi Ali, > > > > >>3.) Now each requester's signature will be verified by the security > > >>module as and when it reaches the service. > > If it passes this step, can I say that "It is coming from one of my > trusted > > senders and it's not intruded during transfer." ? > > Yes. > > > >>4.) At the service you can identify the client that sent the request > > >>using the information available in the message context. > > - Do you mea n that "even the incomming messag e passes the 3th step, I'm > > > still not aware of the sender and if I want to identify the sender, I need > > to follow instructions in 4th step" ? > > - If your answer is "yes", is it possible to do this before executing any > > service instead of at the beginning of each service? > > Answer to both questions is yes. > The inflow security handler will identify the sender and the > information is available in the results vector. You can obtain the > sender information at the service (when the operation is invoked) > before you perform any other processing. You can simply do it anywhere > you like. > > Please note that you should obtain the message context at the service > by adding an init method as shown below: > > public class ServiceClass { > > MessageContext ctx; > > public void init(MessageContext msgCtx) { > ctx = msgCtx; > } > > //The operation that is exposed > public void foo() { > //Get the information from the m sgCtx here and continue > } > > } > > > > > One more question. If I use client side certification based security > model, > > do I still need to authenticate each message? > > IMHO in the simplest case when you use the client's signature (i.e. > the request msg signed by the client) that itself authenticates the > client if the signature is valid and the cert is trusted. Therefore > you don't have to any additional authentication. > > Thanks, > Ruchith > > > Ali Sadik Kumlali <[EMAIL PROTECTED]> wrote: > Hi Ruchith, > > Thank you very much for your quick answer. I'll try every step ASAP. By the > way, just to make sure, I have some questions regarding your answer. > > >>3.) Now each requester's signature will be verified by the security > >>module as and when it reaches the service. > If it passes this step, can I say that "It is coming from one of my trusted > senders and it's not intruded during transfer." ? > > >>4.) At the service you can identify the client that sent the request > >>using the information available in the message context. > - Do you mean that "even the incomming message passes the 3th step, I'm > still not aware of the sender and if I want to identify the sender, I need > to follow instructions in 4th step" ? > - If your answer is "yes", is it possible to do this before executing any > service instead of at the beginning of each service? > > One more question. If I use client side certification based security model, > do I still need to authenticate each message? > > Thanks a lot, > > Ali Sadik Kumlali > > Ruchith Fernando <[EMAIL PROTECTED]> wrote: > Hi Ali, > > You can certainly do what you want with Axis2 using the security module. > You have to make sure that: > > 1.) Configure the service to expect the requests to be signed > > 2.) Public key certificates of each client must be imported into the > service's keystore. This is required in verifying the cert after > signature verification. > > 3.) Now each requester's signature will be verified by the security > module as and when it reaches the service. > > 4.) At the service you can identify the client that sent the request > using the information available in the message context. > > There is a vector of security results available in the message context > by the key WSHandlerConstants.RECV_RESULTS. > Following code snippet shows how to extract the java.security.Principal > > Vector results = null; > // get the result Vector from the property > if ((results = (Vector) > msgContext.getProperty(WSHandlerConstants.RECV_RESULTS))== null) { > System.out.println("No sec urity results!!"); > } > > for (int i = 0; i < results.size(); i++) { > WSHandlerResult hResult = (WSHandlerResult)results.get(i); > String actor = hResult.getActor(); > Vector hResults = hResult.getResults(); > for (int j = 0; j < hResults.size(); j++) { > WSSecurityEngineResult eResult = > (WSSecurityEngineResult)hResults.get(j); > if (eResult.getAction() != WSConstants.SIGN) { > System.out.println(eResult.getPrincipal().getName()); > } > } > } > > > > Thanks, > Ruchith > > On 3/16/06, Ali Sadik Kumlali wrote: > > Dear all, > > > &g t; Sorry if this a strange question, but I'm very new to web service > security > > topic. > > > > Let me list my situation and needs step by step: > > 1) I have many clients > > 2) Each client has its own certificate > > 3) Each client send SOAP messages by signing with its certificate > > 4) I use Axis2 and WS-Security extentions > > 5) I need to recognize each sender uniquely and verify the message > according > > to the sender's own certificate. > > 6) AFAIK, it's not necessary to use Username-token profile if I verify > each > > message with sender's certificate. > > > > Some of the items seems very odd. If you beleive I'm going through correct > > way, please tell me how to build these up with Axis2. Otherwise, please > let > > me know what kind of approach should I use to handle multiple client > > certificates. > > > > Thanks in advance, > > > > Ali Sadik Kumlali > > ________________________________ > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ > countries) for 2�/min or less. > > > > ________________________________ > New Yahoo! Messenger with Voice. Call regular phones from your PC and save > big. > >
