Hi Anand On Fri, Feb 4, 2011 at 6:50 AM, Anand R <[email protected]> wrote:
> Hi Sergey, > > As you mentioned, I added a breakpoint within > WSS4JInInterceptor.handleMessage(). The web service invocation didn't hit > the breakpoint. > WSS4JInInterceptor wasn't present in the chain of interceptors. I added > this interceptor explicitly in my beans.xml. I think I know what is happening. Given a policy is contained in WSDL, PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, CXF adds it itself. Can you give it another try please, remove the explicit WSS4JInInterceptor and add a breakpoint in PolicyBasedWSS4JInInterceptor.handleMessage ? Now I am getting the following exception. > > I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I > am getting the same exception(No security action was defined!). > I tried setting ws-security.ut.no-callbacks on and off. Both result in the > same exception. > > I didn't understand what action is being referred here. I am attaching my > wsdl for your reference. Is this problem anything to do with my policy > specification? > > The wsdl is fine. As I briefly mentioned, the older > AbstractUsernameTokenAuthenticatingInterceptor does not work well with the wsdl first case. It is actually a WSS4JInInterceptor subclass and does all sort of hacks to hide the complexity from the user and provide an (unwrapped) UT to the concrete implementations. However PolicyBasedWSS4JInInterceptor is used instead when the actions are 'embedded' inside a given policy, so registering AbstractUsernameTokenAuthenticatingInterceptor duplicates PolicyBasedWSS4JInInterceptor (you still need to configure the actions even though PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to continue working in the wsdl-first case (provided the no-callbacks property is set) just to minimize the side-effects for the users already doing concrete AbstractUsernameTokenAuthenticatingInterceptor impls. AbstractUsernameTokenAuthenticatingInterceptor is ok for java-first cases but the newer AbstractUsernameTokenInterceptor will work for all the cases. Check please PolicyBasedWSS4JInInterceptor.handleMessage thanks, Sergey > > > org.apache.cxf.binding.soap.SoapFault: No security action was defined! > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196) > at > org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96) > at > org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) > at > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) > at > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > at java.lang.Thread.run(Thread.java:595) > > > Thanks and regards, > Anand > > > > From: Sergey Beryozkin <[email protected]> > To: [email protected] > Date: 03-02-11 07:28 PM > Subject: Re: Problem with AbstractUsernameTokenInInterceptor > ------------------------------ > > > > Hi - I do not understand why it not works. I've checked the code and I see > that no test involving a hashed password exists. Likewise I don't > understand > why it works at the same time with clear passwords and no callbacks. > I'm a bit busy right now, is there any chance that you could download the > source for CXF 2.3.2, remove the ServerCallback property and just add a > breakpoint in WSS4JInInterceptor.handleMessage() ? > > I think you're on the right track. I do not see other options for dealing > with *hashed passwords*, well, unless you;re prepared to do some hacks by > doing the container-managed authentication from the callback itself but > that > would not let you register the proper security context because the one > which > is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal > registered, i.e, no info about roles is available. > > I'd definitely follow this route myself. > Note that AbstractUsernameTokenAuthenticatingInterceptor (in the > ws-security > module) is the other, legacy interceptor that you may also extend - as far > as I know, a 3rd-party container has a test for a hashed UT involving this > particular interceptor. No need to set the "ws-security.ut.no-callbacks", > unless you have a wsdl-first case. Concrete implementations need to extend > a > method with several UT-related parameters which is a bit brittle in that > adding more parameters to the > AbstractUsernameTokenAuthenticatingInterceptor > will break the users' interceptors. > > Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security) > is > recommended because we can easily update CXF UsernameToken bean with the > new > properties ((say the UT salt property, etc)) without the existing users > noticing. > > Debug it if you can - it would help > > Sergey > > > > On Thu, Feb 3, 2011 at 1:02 PM, Anand R <[email protected]> wrote: > > > Hi Sergey, > > > > As you had mentioned earlier, the namespace is > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > > > > Please find the SOAP request message below. > > > > Actually, my requirement is to obtain the username and password from the > > SOAP header to perform container authentication and then associate the > > Subject with the current thread of execution. Am I using the correct > > approach or do I just need to write a SOAPHeaderInterceptor and get the > > required headers. > > > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > > <soap:Header> > > <wsse:Security soap:mustUnderstand="1" > > xmlns:wsse=" > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > > "> > > <wsse:UsernameToken xmlns:wsse=" > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > > " > > xmlns:wsu=" > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd > > " > > wsu:Id="UsernameToken-1"> > > <wsse:Username>libuser</wsse:Username> > > <wsse:Password > > Type=" > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest > > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password> > > <wsse:Nonce EncodingType=" > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary > > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce> > > <wsu:Created>2011-02-03T12:32:27.752Z</ > > wsu:Created> > > </wsse:UsernameToken> > > </wsse:Security> > > </soap:Header> > > <soap:Body> > > <ns2:doEcho xmlns:ns2=" > http://types.echo.wssecurity.learn/ > > "> > > <arg0> > > <echoString>Hello WS-Security</echoString> > > </arg0> > > </ns2:doEcho> > > </soap:Body> > > </soap:Envelope> > > Thanks and regards, > > Anand R > > > > > > > > From: Sergey Beryozkin <[email protected]> > > To: [email protected] > > Date: 03-02-11 05:13 PM > > Subject: Re: Problem with AbstractUsernameTokenInInterceptor > > > > > > > > Hi > > > > WSS4JInInterceptor is already registering a custom UT processor if the > > "ws-security.ut.no-callbacks" is set to true. > > So the hashed UTs should be supported with your configuration, without > the > > need to register a callback. > > Can you give me a favor and check the actual WS-Security namespace that > is > > used to qualify the security header ? You can add a CXF logging feature > to > > the list of jaxws:features > > > > thanks, Sergey > > > > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <[email protected]> wrote: > > > > > Thanks Sergy. I will try the custom UsernameTokenProcessor. > > > Thanks and regards, > > > Anand R > > > > > > > > > > > > From: Sergey Beryozkin <[email protected]> > > > To: [email protected] > > > Date: 03-02-11 04:39 PM > > > Subject: Re: Problem with AbstractUsernameTokenInInterceptor > > > > > > > > > > > > Hi > > > > > > What WS-Security namespace is being used in the request ? > > > If the "ws-security.ut.no-callbacks" is set to true then the > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not be > > > invoked because it does currently require a callback for hashed UTs. So > > if > > > the property is set then the WSS4JInInterceptor registers a custom > > > UsernameTokenProcessor for > > > > > > " > > > > > > > > > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > > > > > > > > " > > > and > > > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";. > > > > > > Thanks, Sergey > > > > > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <[email protected]> > wrote: > > > > > > > Hi Sergey, > > > > > > > > Thanks for your response. I used to get the following exception when > I > > > did > > > > not configure a callback handler. This exception does not come if the > > > > password is plain text instead of a digest. > > > > > > > > org.apache.cxf.interceptor.Fault: General security error > > > > (WSSecurityEngine: No password callback supplied) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) > > > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > > at > > > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) > > > > at > > > > > > > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > > > > at > > > > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > > > > at java.lang.Thread.run(Thread.java:595) > > > > Caused by: org.apache.ws.security.WSSecurityException: General > > security > > > > error (WSSecurityEngine: No password callback supplied) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167) > > > > at > > > > > > > > > > > > > > > > > > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129) > > > > ... 24 more > > > > > > > > > > > > Thanks and regards, > > > > Anand R > > > > System Architect > > > > IBS Software Services Private Limited > > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum - > > > 695581, > > > > Kerala, India > > > > Telephone - +91-471-6614291, Mobile - +91-9846324022 > > > > E-Mail - [email protected], www.ibsplc.com > > > > > > > > > > > > > > > > > > > > From: Sergey Beryozkin <[email protected]> > > > > To: [email protected] > > > > Date: 03-02-11 04:08 PM > > > > Subject: Re: Problem with AbstractUsernameTokenInInterceptor > > > > > > > > > > > > > > > > Hi > > > > > > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <[email protected]> > > wrote: > > > > > > > > > Hi, > > > > > > > > > > My requirement is to perform a custom authentication on the > username > > > and > > > > > password that I receive as part of the UsernameToken header in the > > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an > > > > > AbstractUsernameTokenInInterceptor to perform this. I extended this > > > > class > > > > > and created my interceptor that overrides the createSubject method. > > > When > > > > I > > > > > configure my interceptor in my beans.xml as shown below, I am > > getting > > > an > > > > > exception. > > > > > > > > > > This exception comes up when I use a password digest. The plain > text > > > > > password works fine. Is there any problem in the way I have > > configured > > > > my > > > > > interceptor? > > > > > > > > > > > > > > > Entry in beans.xml > > > > > > > > > > <jaxws:endpoint id="echo" > > > > > implementor="learn.wssecurity.echo.EchoServiceImpl" > > > > > wsdlLocation="wsdl/echo/EchoService.wsdl" > > > > > address="/EchoService"> > > > > > <jaxws:inInterceptors> > > > > > <bean > > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/> > > > > > </jaxws:inInterceptors> > > > > > <jaxws:properties> > > > > > <entry key="ws-security.callback-handler" > > > > > value="learn.wssecurity.echo.ServerPasswordCallback" /> > > > > > <entry key="ws-security.ut.no-callbacks" > > > > > value="true" /> > > > > > </jaxws:properties> > > > > > </jaxws:endpoint> > > > > > > > > > > > > > > > > > > What is the purpose of registering ServerPasswordCallback ? If you > set > > a > > > > "ws-security.ut.no-callbacks" property then you only need a callback > > if > > > > you > > > > have an encrypted UT, so that the UT can be decrypted. > > > > So this callback that you're registering may be interfering in the > > case > > > > when > > > > you have a hashed UT token, can you remove it please and see what > > > happens > > > > ? > > > > > > > > Cheers, Sergey > > > > > > > > > > > > > > > > > > > > > > > > > > Exception > > > > > > > > > > java.lang.SecurityException: Security Token is not available on the > > > > > current message > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java: > > > > > 88) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) > > > > > at > > javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) > > > > > at > > > > > > > > > > > > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > > > > > at > > > > > > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > > > > > at java.lang.Thread.run(Thread.java:595) > > > > > > > > > > Thanks and regards, > > > > > Anand R > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: > > > > > > > > > > "The information in this e-mail and any attachment is intended only > > > for > > > > > the person to whom it is addressed and may contain confidential > > and/or > > > > > privileged material. If you have received this e-mail in error, > > kindly > > > > > contact the sender and destroy all copies of the original > > > communication. > > > > > IBS makes no warranty, express or implied, nor guarantees the > > > accuracy, > > > > > adequacy or completeness of the information contained in this email > > or > > > > any > > > > > attachment and is not liable for any errors, defects, omissions, > > > viruses > > > > > or for resultant loss or damage, if any, direct or indirect." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: > > > > > > > > "The information in this e-mail and any attachment is intended only > > for > > > > the person to whom it is addressed and may contain confidential > and/or > > > > privileged material. If you have received this e-mail in error, > kindly > > > > contact the sender and destroy all copies of the original > > communication. > > > > IBS makes no warranty, express or implied, nor guarantees the > > accuracy, > > > > adequacy or completeness of the information contained in this email > or > > > any > > > > attachment and is not liable for any errors, defects, omissions, > > viruses > > > > or for resultant loss or damage, if any, direct or indirect." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: > > > > > > "The information in this e-mail and any attachment is intended only for > > > the person to whom it is addressed and may contain confidential and/or > > > privileged material. If you have received this e-mail in error, kindly > > > contact the sender and destroy all copies of the original > communication. > > > IBS makes no warranty, express or implied, nor guarantees the accuracy, > > > adequacy or completeness of the information contained in this email or > > any > > > attachment and is not liable for any errors, defects, omissions, > viruses > > > or for resultant loss or damage, if any, direct or indirect." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: > > > > "The information in this e-mail and any attachment is intended only for > > the person to whom it is addressed and may contain confidential and/or > > privileged material. If you have received this e-mail in error, kindly > > contact the sender and destroy all copies of the original communication. > > IBS makes no warranty, express or implied, nor guarantees the accuracy, > > adequacy or completeness of the information contained in this email or > any > > attachment and is not liable for any errors, defects, omissions, viruses > > or for resultant loss or damage, if any, direct or indirect." > > > > > > > > > > > > > > > > > > DISCLAIMER: > > "The information in this e-mail and any attachment is intended only for the > person to whom it is addressed and may contain confidential and/or > privileged material. If you have received this e-mail in error, kindly > contact the sender and destroy all copies of the original communication. IBS > makes no warranty, express or implied, nor guarantees the accuracy, adequacy > or completeness of the information contained in this email or any attachment > and is not liable for any errors, defects, omissions, viruses or for > resultant loss or damage, if any, direct or indirect." > > > > >
