For the fault problem, if the wsdl does not describe suitable faults, we may still be able to find a way out, either by sending a fault that has not been described. It should be possible to throw an unchecked exception (inheriting from RuntimeException). If this exception contains the needed JAXB2 and JAXWS annotations, a fault should be set on the exchange. However, some exchanges are InOnly and won't support faults at all. In such cases, the only way is to set an ERROR on the exchange. Anyway, for a first step, throwing a simple unchecked exception should result in an ERROR, which should be ok for now. Another idea would be to enhance the WSDLs to include a new security fault (it should be from another namespace to easily see this is a ServiceMix specific fault) that could be sent by all the needed operations. I think it would be the best way, but given the OASIS license of the WSDL and XSD, it does not seem possible. We'd have to check with legal.
Btw, quicly looking at the SecurityHandler interface, I don't see any parameters related to the user sending the request. Where do you expect these information to be retrieved ? I think they should be retrieved from the jbi exchange Subject somehow. We could use a ThreadLocal containing the Subject from the JBI exchange. The value would be set before processing any message. Also some methods do not contain parameters at all and I would expect that each one would need to identify the request somehow. But I guess this part has not been finished, as some methods are not called yet. Next time, could you please raise a JIRA issue and attach the code there (make sure you check the box for granting the license to the ASF). Btw, a diff file would be better as we can easily identify the changed parts (you can create it using svn diff after you have checked out the code using svn and modified it). Note that the WS-Notification component has undergone some changes recently to make sure it works well in ServiceMix 4, so it may happen that the patch can't be applied on trunk of this component: https://svn.apache.org/repos/asf/servicemix/components//engines/servicemix-wsn2005/trunk/ On Mon, Sep 29, 2008 at 9:59 AM, Anne Noseda <[EMAIL PROTECTED]> wrote: > > Hello, > > I have finished a first version of the implementation of the > securityhandler. (you can find the source code in attachment : I have worked > on the version servicemix-3.3.0.8-fuse because it's the version the customer > uses). There is still many tthings to add and correct. > > I have defined an additional property "securityhandler" in the > WSNConfigurationMBean and the WSNConfiguration classes which corresponds to > the name of the class which implements SecurityHandler. This property can be > defined in the conf/component.properties file like this : > "servicemix-wsn2005.securityHandlerClassName=org.apache.servicemix.wsn.security.DefaultSecurityHandler". > I have initialized the property in the WSNLifeCycle class and I have called > the SecurityHandler in the AbstractNotificationBroker class before handling > the subscription request for example. > I have taken example on the http-component to do all this "chaining" : I > hope you will like it ! > > I have just some more questions : > > - I only need to check security in 4 situations (before accepting a > subscription, before accepting a publisher registration, before accepting a > publisher notification, before sending a notification) but I think we must > define methods for all possible situations in the security handler. I list > these ones, is it complete ? > 1.before accepting a subscription > 2.before accepting a publisher registration > 3.before accepting a publisher notification > 4.before sending a notification > 5.before pausing a subscription > 6.before resuming a subscription > 7.before renewing a subscription > 8.before accepting an unscubscription > 9.before accepting to destroy a publisher registration > > - is it correct to say that these methods throw an exception if the security > needs are not OK and returns nothing if all is OK ? If yes, the "subscribe" > method throws 3 interesting faults (SubscribeCreationFailedFault, > UnrecognizedPolicyRequestFault, UnsupportedPolicyRequestFault) whiwh can > describe the problem and are defined in the specification but it's not > present for all the methods. What do you think about it ? > > - can you look at the sources and tell me what you think ? > > Thanks in advance, > > Anne. > > > > http://www.nabble.com/file/p19719740/sources_wsn_securityhandler.zip > sources_wsn_securityhandler.zip > > > > Anne Noseda wrote: >> >> Hello, >> >> I will begin to implement the improvements we discussed in the post >> (WS-Notification Component Improvment). I will start with the security >> point. >> The idea was to create an interface "securityhandler" that each developper >> can implement as he need to check security : >> - before accepting subscription; >> - before accepting publisher registration; >> - before sending notification. >> Is it correct to define this property "securityhandler" in the class >> "WSNConfiguration" of the package "org.apache.servicemix.wsn.component" ? >> If yes, how can we configure it ? Indeed, the wsn-component has no >> "xbean.xml" to deploy it as the others components. Is it in the >> conf/component.properties file like this : >> "servicemix-wsn.securityHandler=java\:comp/env/smx/LdapSecurityHandler" >> for example where "java\:comp/env/smx/LdapSecurityHandler" is a jndi key >> to retrieve the object ? >> >> Thanks in advance, >> >> Anne. >> > > -- > View this message in context: > http://www.nabble.com/WS-Notification-Component-Improvement---SecurityHandler-tp19683627p19719740.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://open.iona.com
