You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Dittmann Werner <we...@siemens.com> on 2004/08/19 17:37:33 UTC
AW: AW: AW: [jira] Created: (WSFX-30) Added a few more test scena
rios to TestJAX RPCHandler.java
Venkat,
well having two handles that perform the same thing ...
isn't too bad, its just another set of data, code is shared :-)
About the ST3 secnario: for ST3 it is not mandatory to have a
signaturePropFile because the SAMLIssuerImpl gets all the
necessary info via the saml3.properties (if it is the
sender_vouches case .... if it is holder_of_key case then
signaturePropFile is required....SAML isn't easy :-)) )
The original WsDoAllSender has a piece of code in
performST_SignAction that loads the signaturePropFile
_but_ ignores if it can't be loaded (an empty catch)
It then forwards the loaded crypto class (or null in case
of error) to the SAMLIssuerImpl. SAMLIssuerImpl then either
uses it or not... depending on the case
(sender_vouches - don't use, holder_of_key - use it).
When I checked the latest source I found that someone
disabled a check in SAMLIssuerImpl that checks if
userCrypto is null in case of holder_of_key - this should
be reenabled again to avoid NPE.
regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: Venkat Reddy [mailto:vreddyp@gmail.com]
> Gesendet: Donnerstag, 19. August 2004 16:41
> An: Dittmann Werner
> Cc: fx-dev@ws.apache.org
> Betreff: Re: AW: AW: [jira] Created: (WSFX-30) Added a few
> more test scenarios to TestJAX RPCHandler.java
>
>
> Thanks Werner.
> I have implemented your idea. It works absolutely fine for all the ten
> interop scenarios.
>
> However, the model now resembles the old axis handlers - using
> separate handler instances for request and response even though we
> have handleRequest and handleResponse methods in each of the handler
> fully implemented. I thnk that's fine for now.
>
> On a different note, i've faced a small issue in the STScenario3 for
> not specifying the signaturePropFile. Once i added this handler
> parameter with value of "crypto.properties", it worked fine. What
> puzzled me was Client-deployment.wsdd doesn't have this parameter
> either. Don't know how it works there.
>
> have a great weekned
> Venkat
>
>
>
>
>
> On Wed, 18 Aug 2004 16:33:04 +0200, Dittmann Werner
> <we...@siemens.com> wrote:
> > Fixing a important typo - see at >>>>> marker
> > Werner
> >
> >
> > Venkat,
> >
> > if it is possible to add the same handler class in
> > the handler chain twice with different sets of configs
> > then IMO we can solve the problem.
> >
> > What about the following idea:
> >
> > Define more precise deployment ids:
> > "client-request", "client-response", "server-request"
> > "server-response" instead of only "client" and "server"
> >
> > Then, in the server:
> >
> > if deployment == "client-request" and msgType == request
> > doSender
> > else if deployment == "sender-request" and msgType == request
> > doReceiver
> > else if deployment == "client-response" and msgType == response
> > doReceiver
> > else if deployment == "server-response" and msgType = response
> > doSender
> > else
> > error
> > endif
> >
> > Thus simulating the Axis way to instanciate different handlers
> > on the request and response flow. An even better way would be
> > to have two different handlerChains - one the the request path,
> > one for the response path.
> >
> > The testcase than could go something like that:
> >
> > config.put("deployment", "client-request");
> > config.put("action", "Signature Encrypt Timestamp");
> > config.put("user",
> "1fb7623be7b2f4831ffc3f3741fa09dd_1e149434-9d3a-4adc-9284-4cfd
> c595012f");
> > config.put("passwordCallbackClass",
> "org.apache.ws.axis.oasis.PWCallback1");
> > config.put("signatureKeyIdentifier", "DirectReference");
> > config.put("signaturePropFile", "wsstest.properties");
> > config.put("encryptionKeyIdentifier", "SKIKeyIdentifier");
> > config.put("encryptionUser",
> "c82f74d031dabf9d7546f40ad07c32c0_1e149434-9d3a-4adc-9284-4cfd
> c595012f");
> > handlerChain.add(new HandlerInfo(WSS4JHandler.class, config, null));
> >
> >
> > >>>>>> Thus the handler would _not_ look at the response. <<<<<<
> >
> >
> >
> > This way it is also possible to instanciate two handlers
> > with different sets of configs. Similar to
> >
> > Map other_config = new HashMap();
> > other_config.put("deployment", "client-response");
> > other_config.put("action", "Signature ...");
> > other_config.put("user", "...");
> > .....
> > handlerChain.add(new HandlerInfo(WSS4JHandler.class,
> other_config, null));
> >
> > IMO this could work for programmatically deployment as well as
> > Axis deployment with deployment descriptors.
> >
> > Regards,
> > Werner
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Venkat Reddy [mailto:vreddyp@gmail.com]
> > > Gesendet: Mittwoch, 18. August 2004 15:26
> > > An: Dittmann Werner
> > > Cc: fx-dev@ws.apache.org
> > > Betreff: Re: AW: [jira] Created: (WSFX-30) Added a few more
> > > test scenarios to TestJAX RPCHandler.java
> > >
> > >
> > > hi Werner,
> > >
> > > In these test cases, I'm adding the JAXRPC Handler (WSS4JHandler)
> > > programmatically (service.getHandlerRegistry,
> registry.setHandlerChain
> > > etc.), instead of deploying them through
> Client-config.wsdd. This is
> > > to avoid making changes to the current settings in wsdd file.
> > >
> > > However, i realize that, currently the Client-config.wsdd has
> > > different sets of handler config parameters for request
> and response
> > > flows for the some services. For example, Ping1 has <parameter
> > > name="action" value="UsernameToken"/> for request flow and has no
> > > action defined for response flow. But inside WSS4JHandler, the
> > > doReceiver method, which is invoked for handling the response on
> > > client-side in this case, also sees the action parameter
> and expects
> > > security headers inside the response and fails.
> > >
> > > I was just wondering whether there is a way to specify
> separate sets
> > > of handler config parameters for request and response flows while
> > > deploying the handlers programmatically. If not, what's the best
> > > solution? That's my problem.
> > >
> > > Hope that is much clearer. You can also look into the file
> > > test/interop/TestJAXRPCHandler.java (also attached with
> this mail) to
> > > see what I'm doing.
> > >
> > > Thanks and regards
> > > Venkat
> > >
> > >
> > >
> > > On Wed, 18 Aug 2004 15:02:54 +0200, Dittmann Werner
> > > <we...@siemens.com> wrote:
> > > > Venkat,
> > > >
> > > > what is the problem with the not workinf scenarios? Problems
> > > > in the config (Axis deployment file)? Can you give me some
> > > > hint what goes wrong there?
> > > >
> > > > Regards,
> > > > Werner
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: fx-dev@ws.apache.org [mailto:fx-dev@ws.apache.org]
> > > > > Gesendet: Mittwoch, 18. August 2004 14:46
> > > > > An: fx-dev@ws.apache.org
> > > > > Betreff: [jira] Created: (WSFX-30) Added a few more test
> > > > > scenarios to TestJAX RPCHandler.java
> > > > >
> > > > >
> > > > > Message:
> > > > >
> > > > > A new issue has been created in JIRA.
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > View the issue:
> > > > > http://issues.apache.org/jira/browse/WSFX-30
> > > > >
> > > > > Here is an overview of the issue:
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > Key: WSFX-30
> > > > > Summary: Added a few more test scenarios to TestJAX
> > > > > RPCHandler.java
> > > > > Type: Improvement
> > > > >
> > > > > Status: Unassigned
> > > > > Priority: Minor
> > > > >
> > > > > Project: WSFX
> > > > > Components:
> > > > > WSS4J
> > > > >
> > > > > Assignee:
> > > > > Reporter: Venkat Reddy
> > > > >
> > > > > Created: Wed, 18 Aug 2004 5:44 AM
> > > > > Updated: Wed, 18 Aug 2004 5:44 AM
> > > > >
> > > > > Description:
> > > > > Scenarios 3, 4 and 6 are working fine right now. The code for
> > > > > the remaining scenarios (1, 2, 5 and 7) also added but yet to
> > > > > be fixed, and is currently commented out. They fail because
> > > > > the same set of handler config parameters do not work for
> > > > > both request and response flows. I'm still thinking on how to
> > > > > fix this. Does anybody have suggestions on how to fix
> for this?
> > > > >
> > > > > Thanks
> > > > > Venkat
> > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > JIRA INFORMATION:
> > > > > This message is automatically generated by JIRA.
> > > > >
> > > > > If you think it was sent incorrectly contact one of the
> > > > > administrators:
> > > > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > > >
> > > > > If you want more information on JIRA, or have a bug
> to report see:
> > > > > http://www.atlassian.com/software/jira
> > > > >
> > > >
> > >
> >
>