Sorry, I was rushing through the mail and I think got your requirement wrong. So the setting the setProcessed doesn't make any difference in this situation. But may be adding a default security header for guest privilege messages would do. (just thinking aloud) What is preventing you from using the solution suggested by Prabath / RampartFAQ blog post ?
regards, Nandana On Tue, Aug 25, 2009 at 11:52 AM, Nandana Mihindukulasooriya < nandana....@gmail.com> wrote: > I totally agree with Prabath, I also think disengaging Rampart is not the > correct approach. If we take one example to clarify. Most of the time, > Rampart is engaged at service level and depending the service session scope > of your service, there can be only one AxisService description object for > the complete life cycle of the service. So you are doing a service level > change for a message level behavior. This can lead to race conditions IMHO. > > I think the best apporach to have two EPRs as mentioned in the RampartFAQ > blog, one secured and one non secured. That seems to be the most reasonable > way to handle this. > > But if you really really want to go with your approach (which is not > recommened), what you should do in the handler is to make setProcessed true > in the security header. > > SOAPHeaderElement.setProcessed(true); > > I know, alternative policy support was handing there for somtime but > unfortunetly anyone of us didn't have time to invest on that. As it seems a > common requirement, I also thinks it is very good feature addtion for > Rampart. If someone can volunteer to implement this and invest sometime on > this, I think all the Rampart team will be more than happy to help. > > regards, > nadnana > > > On Tue, Aug 25, 2009 at 10:07 AM, prabath <prab...@wso2.com> wrote: > >> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> > > >
