Hi Kaushalye, OK. This makes sense now. That means REST should not work for a WS-Security service. That's because WS-Security must ensure service level security. I believe it is better if you could make users aware that you can't make the secure services available as REST, as Axis2/C says, any service can be either SOAP or REST.
Regards, Senaka > Hi Senaka, > As I said earlier, if a user enabled WS-Security, the service is > expecting SOAP messages. That means if there are not credentials in the > SOAP header the security phase will block the message. Practically it is > not advisable and not practical too to build same message using REST. > Think about encrypted messages where lots of random parameters comes to > play. > If the user likes to expose the same business logic using REST he is > free to do so with another service. But I repeat it has some security > vulnerabilities. One is secured and other is less. Note that the > strength of a chain is in its weakest link. :-) > Cheers, > Kau > > Senaka Fernando wrote: >> Hi Kaushalye, >> >> I know that Rampart/C is only for SOAP. I mean if someone exposes a >> WS-Security enabled service as REST, what would be the behaviour? >> >> Regards, >> Senaka >> >> >>> Senaka Fernando wrote: >>> >>>> Hi Kaushalye, >>>> >>>> Does this mean no-REST with Rampart/C services??? >>>> >>> What are Rampart/C service? If you mean secured services, Apache >>> Ramaprt/C is only for SOAP. >>> >>>> That's a big issue I >>>> guess. Why isn't it possible to make partially secure services. The >>>> whole >>>> idea is to meet the requirement of a provider. If he can't partially >>>> secure then he would rather drop WS-Security. This won't solve at >>>> least >>>> some of his expectations. Thoughts?? >>>> >>>> >>> What are partially secured services? A service is either secured or >>> not.:) The same service cannot be allowed to treat two requests in >>> different ways. For example think about authentication. What's the >>> rationale behind allowing one request to add claims and another to not? >>> Why would I bother adding username tokens if the service is kind enough >>> to pass without them? >>> Cheers, >>> Kau >>> >>> >>>> Regards, >>>> Senaka >>>> >>>> >>>> >>>>> Hi Kaushalye and Supun, >>>>> >>>>> Thanks for your responses. So I would think REST calls will also >>>>> only >>>>> work if I am not configuring the service to use rampart, correct? >>>>> You >>>>> are right that I can define 2 services and leave one open for REST >>>>> and >>>>> other means of security. The customer will decide what they want >>>>> based >>>>> on where they are deploying their service. >>>>> >>>>> -Dave. >>>>> >>>>> -----Original Message----- >>>>> From: Kaushalye Kapuruge [mailto:[EMAIL PROTECTED] >>>>> Sent: Thursday, February 21, 2008 9:38 PM >>>>> To: rampart-c-dev@ws.apache.org >>>>> Subject: Re: [RAMPART/C] Question about making the WS-SECURITY >>>>> optional >>>>> from call to call >>>>> >>>>> Hi, >>>>> Having different security requirements for the same endpoint doesn't >>>>> make any sense. A service should treat all incoming messages in the >>>>> same >>>>> way. >>>>> Saying that, we do not support the operational level security. The >>>>> smallest unit of security requirements is for a service. So if you >>>>> need >>>>> to have different security requirements, you need to have different >>>>> services. Then again, you have to be careful exposing your business >>>>> logic. If a secured service is exposed with another then an attacker >>>>> can >>>>> easily pick the latter.:) Cheers, Kau >>>>> >>>>> Dave Meier wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I want to support WS-SECURITY on request coming in to my server, but >>>>>> I >>>>>> >>>>>> also want clients to be able to send SOAP requests with no >>>>>> WS-SECURITY >>>>>> >>>>>> and provide the userid/password by inserting them into the request >>>>>> as >>>>>> regular elements. I also want my REST calls to work without RAMPART >>>>>> doing anything with them. Is there a way to configure the server >>>>>> this >>>>>> >>>>>> way? >>>>>> >>>>>> So I want to support the following all with one services.xml file: >>>>>> >>>>>> 1. SOAP WS-SECURITY requests. >>>>>> 2. SOAP requests with no WS-SECURITY header. >>>>>> 3. REST calls. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Dave. >>>>>> >>>>>> >>>>>> ********************************************************************** >>>>>> This email and any files transmitted with it are confidential and >>>>>> >>>>>> >>>>> intended solely for the use of the individual or entity to whom they >>>>> are >>>>> addressed. Any unauthorized review, use, disclosure or distribution >>>>> is >>>>> prohibited. If you are not the intended recipient, please contact the >>>>> sender by reply e-mail and destroy all copies of the original >>>>> message. >>>>> >>>>> >>>>>> ********************************************************************** >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> http://blog.kaushalye.org/ >>>>> http://wso2.org/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> http://blog.kaushalye.org/ >>> http://wso2.org/ >>> >>> >>> >> >> >> > > > -- > http://blog.kaushalye.org/ > http://wso2.org/ > >
