hi George/Prabath, thanks for all your competent answers!
George understood it correctly (sorry if I was not clear), I'm searching for a solution where a method is accessible in both secured and non-secured way, where with security headers a different access level is granted than with no security headers. I'm not completly sure, but I think I tried these so called alternative policies described here: http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy.pdf Good to know that this is not implemented yet, because I tried also to debugg rampart, which always considered only the first policy, and if that policy didn't match it throw the exception, without considering the following ones... Now I'm evaluating Prabath's blog entry (many thx for that). I will check if that would be suitable for the clients... Although it seems to be a clean workaround! And clients which are using our system are experts in their domain, so it should be possible for them to switch between different bindings (depending on their needs). Disabling the rampart module would be an option to disable security for the whole webservice system on runtime (if the administrator wants that).. But maybe I can find a better solution for that? I will update you about what solution we took! Best regards Michael prabath schrieb: > Hi George/Michael ; > > What I was suggesting disengaging rampart is not a good approach. If > so what happens to the requests come with a security header at the > time Rampart being disengaged. > > Yes - Rampart doesn't support policy alternatives yet - but here[1] I > explain how you could do this with out policy alternatives - hope that > will help. > > Thanks & regards. > -Prabath > > [1]:http://blog.RampartFAQ.com/2009/08/how-to-add-secured-and-non-secured-end.html > > > George Stanchev wrote: >> Well, here are quotes from the OP's email: >> >> "I'm searching for a solution to make security headers optional." >> "I would like to customize the error message, <b>or I would like to >> allow >> the requester to execute all methods with guest privilges (done by our >> system).</b>" >> >> You are saying I have misread what he wants? >> >> >From what I understand he wants EXCACTLY what alternative policies >> provide, >> which is currently not implemented. If he applies security at some >> operations and strips others from security, how would those non-secured >> operations process security when supplied? He wants the methods to be >> accessible in both secured and non-secured calls. If security is >> supplied >> then it is processed, verified and if conforming to the policy, then a >> different access level would be granted by his business-level processing >> code. If non-secure call is made, then some guest priviliges would be >> granted but the call still needs to make it through. >> >> George >> >> >>>> Michael Rogger wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> That means, if the client provides security headers good, >>>>> if the client does not provide security headers, no exception >>>>> should be >>>>> thrown! >>>>> >>>>> I would like to customize the error message, or I would like to allow >>>>> the requester to execute all methods with guest privilges (done by >>>>> our >>>>> system). >> >> -----Original Message----- >> From: prabath [mailto:prab...@wso2.com] Sent: Monday, August 24, 2009 >> 6:25 PM >> To: rampart-dev@ws.apache.org >> Subject: Re: Security Headers - Optional? >> >> George Stanchev wrote: >> >>> Your best bet is to create a handler and put it infront of rampart that >>> dynamically engages and disengages >>> rampart based on the presense of wsse:Security header. A hack solution >>> >> until >> >>> alternative policy support >>> comes into rampart >>> >> Disengaging Rampart dynamically is not the correct solution for what >> Michael needs. Even when no security headers present he does not want >> to let users access the service - just want to send back a customized >> message instead of the stack trace. >> >> Michael, if you want some non-critical methods to be non-secure - the >> correct approach is to apply security at the operation level. >> >> Thanks & regards. >> -Prabath >> http://RampartFAQ.com >> >>> George >>> -----Original Message----- >>> From: Michael Rogger [mailto:michael.rog...@sti2.at] Sent: Monday, >>> August 24, 2009 6:35 AM >>> To: rampart-dev@ws.apache.org >>> Subject: Re: Security Headers - Optional? >>> >>> Thanks for your fast reply! >>> >>> Yeah that is true, but if a requester doesn't know about security >>> headers, I prefer to give him a customized output message instead of a >>> stack trace... >>> With an optional security header it would be also possible to allow the >>> client to execute at least not critical methods where no authentication >>> is requiered.. (encryption and signing not considered) >>> >>> Is it somehow possible do make the security header optional? I could >>> not >>> find a configuration parameter? >>> >>> Best regards >>> Michael >>> >>> prabath schrieb: >>> >>>> Hi Michael; >>>> >>>> Can you please elaborate more on your requirement... >>>> >>>> If it is optional - that means your service in insecure. >>>> >>>> Thanks & regards. >>>> -Prabath >>>> http://RampartFAQ.com >>>> >>>> Michael Rogger wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm searching for a solution to make security headers optional. >>>>> >>>>> That means, if the client provides security headers good, >>>>> if the client does not provide security headers, no exception >>>>> should be >>>>> thrown! >>>>> >>>>> I would like to customize the error message, or I would like to allow >>>>> the requester to execute all methods with guest privilges (done by >>>>> our >>>>> system). >>>>> >>>>> My question, is it possible to make security headers optional? >>>>> >>>>> Thanks for your answer! >>>>> Best regards >>>>> Michael >>>>> >>>>> >>> >>> >> >> >> >> >
