You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by vannguyen0 <vn...@ur.com> on 2007/08/28 18:30:41 UTC
Method level authentication?
Hi,
I'm fairly new to webservices and was wondering if CXF has the ability to
restrict users to certain web services methods. If I have
PerformProductSearch and UpdateProductInformation, I want to allow user A
(or users that is in user group A) permission to only PerformProductSearch.
But user B (or users that are in user group B) can access to both methods.
Thanks,
Van
--
View this message in context: http://www.nabble.com/Method-level-authentication--tf4342781.html#a12371372
Sent from the cxf-user mailing list archive at Nabble.com.
Re: basic auth with JaxWsProxyFactoryBean
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 30 August 2007, Chris Campbell wrote:
> I want to setup basic auth, using an AuthInterceptor on the server
> side, as discussed in another thread.
>
> I am using JaxWsProxyFactoryBean on client side, simple frontend
> style, but it is unclear to me how to put the AuthorizationPolicy
> object into the request.
There are basically three ways:
Standard JAX-WS way:
BindingProvider bp = (BindingProvider)port;
bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "BJ");
bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "pswd");
(note the keys MUST be the BindingProvider keys, not just "username")
Purely CXF way per request:
AuthorizationPolicy policy = new AuthorizationPolicy ();
policy.setUsername("...");
policy.setPassword("...");
BindingProvider bp = (BindingProvider)port;
bp.getRequestContext().put(AuthorizationPolicy.class.getName(), policy);
Purely CXF way to control the conduit directly:
Client client = ClientProxy.getClient(greeter);
HTTPConduit httpConduit = (HTTPConduit)client.getConduit();
AuthorizationPolicy policy = new AuthorizationPolicy();
policy.setUserName("BJ2");
policy.setPassword("pswd");
httpConduit.setAuthorization(policy);
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
Yes, that does it. Will look forward to the patch, but I can use
this temporarily, thank you very much.
chris
Daniel Kulp wrote:
> Well, you could query the header yourself (lowercase version) and do all
> the decoding yourself in your interceptor:
>
> Map<String, List<String>> requestHeaders;
> requestHeaders = message.get(Message.PROTOCOL_HEADERS)
> if (requestHeaders.containsKey("authorization")) {
> List<String> authorizationLines =
> requestHeaders.get("authorization");
> String credentials = authorizationLines.get(0);
> String authType = credentials.split(" ")[0];
> if ("Basic".equals(authType)) {
> String authEncoded = credentials.split(" ")[1];
> try {
> String authDecoded = new
> String(Base64Utility.decode(authEncoded));
> String authInfo[] = authDecoded.split(":");
> String username = authInfo[0];
> String password = authInfo[1];
>
> AuthorizationPolicy policy = new
> AuthorizationPolicy();
> policy.setUserName(username);
> policy.setPassword(password);
>
> message.put(AuthorizationPolicy.class, policy);
> } catch (Base64Exception ex) {
> //ignore, we'll leave things alone. They can try
> decoding it themselves
> }
> }
> }
>
> Kind of blows. I'll get a fix committed to trunk today. Will be fixed
> for 2.0.2.
>
> Dan
>
>
> On Friday 31 August 2007, Chris Campbell wrote:
>> Wow, nice one. Is there anyway I can get around this without
>> dropping Tomcat? Thanks again.
>>
>> chris
>>
>> Daniel Kulp wrote:
>>> OK. Figured this out. Tomcat is lowercasing everything when we
>>> query them from the HttpServletRequest. However, we're
>>> specifically looking for the "Authorization" header, not
>>> "authorization". Jetty seems to leave the case alone.
>>>
>>> Dan
>>>
>>> On Friday 31 August 2007, Chris Campbell wrote:
>>>> I do see an Authorization header
>>>>
>>>> Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
>>>>
>>>> Daniel Kulp wrote:
>>>>> There's been a couple people having issues with basic auth lately.
>>>>> Unfortunately, I haven't been able to reproduce any of it. :-(
>>>>>
>>>>> I THINK it's a client side thing. To check, wireshark the tcp
>>>>> socket and see if there is an Authorization HTTP header. If not,
>>>>> it's a client side issue. That said, the simple cases I've done
>>>>> all have worked fine. The header is there. My gut feeling
>>>>> says there is some spring config thing or policy thing or similar
>>>>> that is causing a conflict and is causing the header to no be
>>>>> written. I'll probably need a fairly detailed test case (client
>>>>> side + wsdl would be fine for now, shouldn't need server side
>>>>> stuff) that has all the configs, code, etc... I've tried
>>>>> several things and I'm always seeing the header, but I'm
>>>>> definitely not familiar enough with the policy stuff to get that
>>>>> completely configured to see if that's the issue.
>>>>>
>>>>> Dan
>>>>>
>>>>> On Friday 31 August 2007, Chris Campbell wrote:
>>>>>> Yes, http, and CXFServlet is running in Tomcat 5.5
>>>>>>
>>>>>> Fred Dushin wrote:
>>>>>>> Just to be sure, are you using HTTP?
>>>>>>>
>>>>>>> Also, are you using the Jetty HTTP destination on the server
>>>>>>> side, or Tomcat?
>>>>>>>
>>>>>>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
>>>>>>>> The AuthorizationPolicy is null in the server interceptor.
>>>>>>>>
>>>>>>>> Now my client does this
>>>>>>>>
>>>>>>>> BindingProvider bp = (BindingProvider)client;
>>>>>>>> java.util.Map<String, Object> context = bp.getRequestContext();
>>>>>>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
>>>>>>>> "foouser");
>>>>>>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
>>>>>>>> "foopass");
>>>>>>>>
>>>>>>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
>>>>>>>> interceptor)
>>>>>>>>
>>>>>>>> // policy is always null here...
>>>>>>>> AuthorizationPolicy policy =
>>>>>>>> message.get(AuthorizationPolicy.class); String username =
>>>>>>>> policy.getUserName();
>>>>>>>> String password = policy.getPassword();
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Daniel Kulp wrote:
>>>>>>>>> On Thursday 30 August 2007, Chris Campbell wrote:
>>>>>>>>>> On client I have:
>>>>>>>>>>
>>>>>>>>>> java.util.Map<String, Object> context =
>>>>>>>>>>
>>>>>>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>>>>>>>>> context.put("username", "chris");
>>>>>>>>>> context.put("password", "foobar");
>>>>>>>>>>
>>>>>>>>>> How do I access that context on the server side in my
>>>>>>>>>> interceptor? I cannot seem to find where it is in the Message
>>>>>>>>>> object, or am I horribly misunderstanding something?
>>>>>>>>> With those keys, they wouldn't get to the server. You would
>>>>>>>>> need to use the BindingProvider.* keys.
>>>>>>>>>
>>>>>>>>> On the server side in an interceptor, you should be able to
>>>>>>>>> do: AuthorizationPolicy policy =
>>>>>>>>> message.get(AuthorizationPolicy.class);
>
>
>
Re: basic auth question
Posted by Daniel Kulp <dk...@apache.org>.
Well, you could query the header yourself (lowercase version) and do all
the decoding yourself in your interceptor:
Map<String, List<String>> requestHeaders;
requestHeaders = message.get(Message.PROTOCOL_HEADERS)
if (requestHeaders.containsKey("authorization")) {
List<String> authorizationLines =
requestHeaders.get("authorization");
String credentials = authorizationLines.get(0);
String authType = credentials.split(" ")[0];
if ("Basic".equals(authType)) {
String authEncoded = credentials.split(" ")[1];
try {
String authDecoded = new
String(Base64Utility.decode(authEncoded));
String authInfo[] = authDecoded.split(":");
String username = authInfo[0];
String password = authInfo[1];
AuthorizationPolicy policy = new
AuthorizationPolicy();
policy.setUserName(username);
policy.setPassword(password);
message.put(AuthorizationPolicy.class, policy);
} catch (Base64Exception ex) {
//ignore, we'll leave things alone. They can try
decoding it themselves
}
}
}
Kind of blows. I'll get a fix committed to trunk today. Will be fixed
for 2.0.2.
Dan
On Friday 31 August 2007, Chris Campbell wrote:
> Wow, nice one. Is there anyway I can get around this without
> dropping Tomcat? Thanks again.
>
> chris
>
> Daniel Kulp wrote:
> > OK. Figured this out. Tomcat is lowercasing everything when we
> > query them from the HttpServletRequest. However, we're
> > specifically looking for the "Authorization" header, not
> > "authorization". Jetty seems to leave the case alone.
> >
> > Dan
> >
> > On Friday 31 August 2007, Chris Campbell wrote:
> >> I do see an Authorization header
> >>
> >> Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
> >>
> >> Daniel Kulp wrote:
> >>> There's been a couple people having issues with basic auth lately.
> >>> Unfortunately, I haven't been able to reproduce any of it. :-(
> >>>
> >>> I THINK it's a client side thing. To check, wireshark the tcp
> >>> socket and see if there is an Authorization HTTP header. If not,
> >>> it's a client side issue. That said, the simple cases I've done
> >>> all have worked fine. The header is there. My gut feeling
> >>> says there is some spring config thing or policy thing or similar
> >>> that is causing a conflict and is causing the header to no be
> >>> written. I'll probably need a fairly detailed test case (client
> >>> side + wsdl would be fine for now, shouldn't need server side
> >>> stuff) that has all the configs, code, etc... I've tried
> >>> several things and I'm always seeing the header, but I'm
> >>> definitely not familiar enough with the policy stuff to get that
> >>> completely configured to see if that's the issue.
> >>>
> >>> Dan
> >>>
> >>> On Friday 31 August 2007, Chris Campbell wrote:
> >>>> Yes, http, and CXFServlet is running in Tomcat 5.5
> >>>>
> >>>> Fred Dushin wrote:
> >>>>> Just to be sure, are you using HTTP?
> >>>>>
> >>>>> Also, are you using the Jetty HTTP destination on the server
> >>>>> side, or Tomcat?
> >>>>>
> >>>>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
> >>>>>> The AuthorizationPolicy is null in the server interceptor.
> >>>>>>
> >>>>>> Now my client does this
> >>>>>>
> >>>>>> BindingProvider bp = (BindingProvider)client;
> >>>>>> java.util.Map<String, Object> context = bp.getRequestContext();
> >>>>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
> >>>>>> "foouser");
> >>>>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
> >>>>>> "foopass");
> >>>>>>
> >>>>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
> >>>>>> interceptor)
> >>>>>>
> >>>>>> // policy is always null here...
> >>>>>> AuthorizationPolicy policy =
> >>>>>> message.get(AuthorizationPolicy.class); String username =
> >>>>>> policy.getUserName();
> >>>>>> String password = policy.getPassword();
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> Daniel Kulp wrote:
> >>>>>>> On Thursday 30 August 2007, Chris Campbell wrote:
> >>>>>>>> On client I have:
> >>>>>>>>
> >>>>>>>> java.util.Map<String, Object> context =
> >>>>>>>>
> >>>>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
> >>>>>>>> context.put("username", "chris");
> >>>>>>>> context.put("password", "foobar");
> >>>>>>>>
> >>>>>>>> How do I access that context on the server side in my
> >>>>>>>> interceptor? I cannot seem to find where it is in the Message
> >>>>>>>> object, or am I horribly misunderstanding something?
> >>>>>>>
> >>>>>>> With those keys, they wouldn't get to the server. You would
> >>>>>>> need to use the BindingProvider.* keys.
> >>>>>>>
> >>>>>>> On the server side in an interceptor, you should be able to
> >>>>>>> do: AuthorizationPolicy policy =
> >>>>>>> message.get(AuthorizationPolicy.class);
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
Wow, nice one. Is there anyway I can get around this without
dropping Tomcat? Thanks again.
chris
Daniel Kulp wrote:
> OK. Figured this out. Tomcat is lowercasing everything when we query
> them from the HttpServletRequest. However, we're specifically looking
> for the "Authorization" header, not "authorization". Jetty seems to
> leave the case alone.
>
> Dan
>
>
> On Friday 31 August 2007, Chris Campbell wrote:
>> I do see an Authorization header
>>
>> Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
>>
>> Daniel Kulp wrote:
>>> There's been a couple people having issues with basic auth lately.
>>> Unfortunately, I haven't been able to reproduce any of it. :-(
>>>
>>> I THINK it's a client side thing. To check, wireshark the tcp
>>> socket and see if there is an Authorization HTTP header. If not,
>>> it's a client side issue. That said, the simple cases I've done
>>> all have worked fine. The header is there. My gut feeling says
>>> there is some spring config thing or policy thing or similar that is
>>> causing a conflict and is causing the header to no be written.
>>> I'll probably need a fairly detailed test case (client side + wsdl
>>> would be fine for now, shouldn't need server side stuff) that has
>>> all the configs, code, etc... I've tried several things and I'm
>>> always seeing the header, but I'm definitely not familiar enough
>>> with the policy stuff to get that completely configured to see if
>>> that's the issue.
>>>
>>> Dan
>>>
>>> On Friday 31 August 2007, Chris Campbell wrote:
>>>> Yes, http, and CXFServlet is running in Tomcat 5.5
>>>>
>>>> Fred Dushin wrote:
>>>>> Just to be sure, are you using HTTP?
>>>>>
>>>>> Also, are you using the Jetty HTTP destination on the server side,
>>>>> or Tomcat?
>>>>>
>>>>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
>>>>>> The AuthorizationPolicy is null in the server interceptor.
>>>>>>
>>>>>> Now my client does this
>>>>>>
>>>>>> BindingProvider bp = (BindingProvider)client;
>>>>>> java.util.Map<String, Object> context = bp.getRequestContext();
>>>>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
>>>>>> "foouser");
>>>>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
>>>>>> "foopass");
>>>>>>
>>>>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
>>>>>> interceptor)
>>>>>>
>>>>>> // policy is always null here...
>>>>>> AuthorizationPolicy policy =
>>>>>> message.get(AuthorizationPolicy.class); String username =
>>>>>> policy.getUserName();
>>>>>> String password = policy.getPassword();
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Daniel Kulp wrote:
>>>>>>> On Thursday 30 August 2007, Chris Campbell wrote:
>>>>>>>> On client I have:
>>>>>>>>
>>>>>>>> java.util.Map<String, Object> context =
>>>>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>>>>>>> context.put("username", "chris");
>>>>>>>> context.put("password", "foobar");
>>>>>>>>
>>>>>>>> How do I access that context on the server side in my
>>>>>>>> interceptor? I cannot seem to find where it is in the Message
>>>>>>>> object, or am I horribly misunderstanding something?
>>>>>>> With those keys, they wouldn't get to the server. You would
>>>>>>> need to use the BindingProvider.* keys.
>>>>>>>
>>>>>>> On the server side in an interceptor, you should be able to do:
>>>>>>> AuthorizationPolicy policy =
>>>>>>> message.get(AuthorizationPolicy.class);
>
>
>
Re: basic auth question
Posted by Fred Dushin <fr...@dushin.net>.
Interesting. I wonder if we should make our context maps non-case-
sensitive in their keys. This may require that we use sortable maps,
though.
-Fred
On Aug 31, 2007, at 3:55 PM, Daniel Kulp wrote:
> OK. Figured this out. Tomcat is lowercasing everything when we
> query
> them from the HttpServletRequest. However, we're specifically
> looking
> for the "Authorization" header, not "authorization". Jetty seems to
> leave the case alone.
Re: basic auth question
Posted by Daniel Kulp <dk...@apache.org>.
OK. Figured this out. Tomcat is lowercasing everything when we query
them from the HttpServletRequest. However, we're specifically looking
for the "Authorization" header, not "authorization". Jetty seems to
leave the case alone.
Dan
On Friday 31 August 2007, Chris Campbell wrote:
> I do see an Authorization header
>
> Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
>
> Daniel Kulp wrote:
> > There's been a couple people having issues with basic auth lately.
> > Unfortunately, I haven't been able to reproduce any of it. :-(
> >
> > I THINK it's a client side thing. To check, wireshark the tcp
> > socket and see if there is an Authorization HTTP header. If not,
> > it's a client side issue. That said, the simple cases I've done
> > all have worked fine. The header is there. My gut feeling says
> > there is some spring config thing or policy thing or similar that is
> > causing a conflict and is causing the header to no be written.
> > I'll probably need a fairly detailed test case (client side + wsdl
> > would be fine for now, shouldn't need server side stuff) that has
> > all the configs, code, etc... I've tried several things and I'm
> > always seeing the header, but I'm definitely not familiar enough
> > with the policy stuff to get that completely configured to see if
> > that's the issue.
> >
> > Dan
> >
> > On Friday 31 August 2007, Chris Campbell wrote:
> >> Yes, http, and CXFServlet is running in Tomcat 5.5
> >>
> >> Fred Dushin wrote:
> >>> Just to be sure, are you using HTTP?
> >>>
> >>> Also, are you using the Jetty HTTP destination on the server side,
> >>> or Tomcat?
> >>>
> >>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
> >>>> The AuthorizationPolicy is null in the server interceptor.
> >>>>
> >>>> Now my client does this
> >>>>
> >>>> BindingProvider bp = (BindingProvider)client;
> >>>> java.util.Map<String, Object> context = bp.getRequestContext();
> >>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
> >>>> "foouser");
> >>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
> >>>> "foopass");
> >>>>
> >>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
> >>>> interceptor)
> >>>>
> >>>> // policy is always null here...
> >>>> AuthorizationPolicy policy =
> >>>> message.get(AuthorizationPolicy.class); String username =
> >>>> policy.getUserName();
> >>>> String password = policy.getPassword();
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Daniel Kulp wrote:
> >>>>> On Thursday 30 August 2007, Chris Campbell wrote:
> >>>>>> On client I have:
> >>>>>>
> >>>>>> java.util.Map<String, Object> context =
> >>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
> >>>>>> context.put("username", "chris");
> >>>>>> context.put("password", "foobar");
> >>>>>>
> >>>>>> How do I access that context on the server side in my
> >>>>>> interceptor? I cannot seem to find where it is in the Message
> >>>>>> object, or am I horribly misunderstanding something?
> >>>>>
> >>>>> With those keys, they wouldn't get to the server. You would
> >>>>> need to use the BindingProvider.* keys.
> >>>>>
> >>>>> On the server side in an interceptor, you should be able to do:
> >>>>> AuthorizationPolicy policy =
> >>>>> message.get(AuthorizationPolicy.class);
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
I do see an Authorization header
Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
Daniel Kulp wrote:
> There's been a couple people having issues with basic auth lately.
> Unfortunately, I haven't been able to reproduce any of it. :-(
>
> I THINK it's a client side thing. To check, wireshark the tcp socket
> and see if there is an Authorization HTTP header. If not, it's a
> client side issue. That said, the simple cases I've done all have
> worked fine. The header is there. My gut feeling says there is some
> spring config thing or policy thing or similar that is causing a
> conflict and is causing the header to no be written. I'll probably
> need a fairly detailed test case (client side + wsdl would be fine for
> now, shouldn't need server side stuff) that has all the configs, code,
> etc... I've tried several things and I'm always seeing the header,
> but I'm definitely not familiar enough with the policy stuff to get that
> completely configured to see if that's the issue.
>
> Dan
>
> On Friday 31 August 2007, Chris Campbell wrote:
>> Yes, http, and CXFServlet is running in Tomcat 5.5
>>
>> Fred Dushin wrote:
>>> Just to be sure, are you using HTTP?
>>>
>>> Also, are you using the Jetty HTTP destination on the server side,
>>> or Tomcat?
>>>
>>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
>>>> The AuthorizationPolicy is null in the server interceptor.
>>>>
>>>> Now my client does this
>>>>
>>>> BindingProvider bp = (BindingProvider)client;
>>>> java.util.Map<String, Object> context = bp.getRequestContext();
>>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
>>>> "foouser");
>>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
>>>> "foopass");
>>>>
>>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
>>>> interceptor)
>>>>
>>>> // policy is always null here...
>>>> AuthorizationPolicy policy =
>>>> message.get(AuthorizationPolicy.class); String username =
>>>> policy.getUserName();
>>>> String password = policy.getPassword();
>>>>
>>>> Thanks.
>>>>
>>>> Daniel Kulp wrote:
>>>>> On Thursday 30 August 2007, Chris Campbell wrote:
>>>>>> On client I have:
>>>>>>
>>>>>> java.util.Map<String, Object> context =
>>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>>>>> context.put("username", "chris");
>>>>>> context.put("password", "foobar");
>>>>>>
>>>>>> How do I access that context on the server side in my
>>>>>> interceptor? I cannot seem to find where it is in the Message
>>>>>> object, or am I horribly misunderstanding something?
>>>>> With those keys, they wouldn't get to the server. You would
>>>>> need to use the BindingProvider.* keys.
>>>>>
>>>>> On the server side in an interceptor, you should be able to do:
>>>>> AuthorizationPolicy policy =
>>>>> message.get(AuthorizationPolicy.class);
>
>
>
Re: basic auth question
Posted by Daniel Kulp <dk...@apache.org>.
There's been a couple people having issues with basic auth lately.
Unfortunately, I haven't been able to reproduce any of it. :-(
I THINK it's a client side thing. To check, wireshark the tcp socket
and see if there is an Authorization HTTP header. If not, it's a
client side issue. That said, the simple cases I've done all have
worked fine. The header is there. My gut feeling says there is some
spring config thing or policy thing or similar that is causing a
conflict and is causing the header to no be written. I'll probably
need a fairly detailed test case (client side + wsdl would be fine for
now, shouldn't need server side stuff) that has all the configs, code,
etc... I've tried several things and I'm always seeing the header,
but I'm definitely not familiar enough with the policy stuff to get that
completely configured to see if that's the issue.
Dan
On Friday 31 August 2007, Chris Campbell wrote:
> Yes, http, and CXFServlet is running in Tomcat 5.5
>
> Fred Dushin wrote:
> > Just to be sure, are you using HTTP?
> >
> > Also, are you using the Jetty HTTP destination on the server side,
> > or Tomcat?
> >
> > On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
> >> The AuthorizationPolicy is null in the server interceptor.
> >>
> >> Now my client does this
> >>
> >> BindingProvider bp = (BindingProvider)client;
> >> java.util.Map<String, Object> context = bp.getRequestContext();
> >> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
> >> "foouser");
> >> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
> >> "foopass");
> >>
> >> My server interceptor does this (it is a Phase.USER_LOGICAL in
> >> interceptor)
> >>
> >> // policy is always null here...
> >> AuthorizationPolicy policy =
> >> message.get(AuthorizationPolicy.class); String username =
> >> policy.getUserName();
> >> String password = policy.getPassword();
> >>
> >> Thanks.
> >>
> >> Daniel Kulp wrote:
> >>> On Thursday 30 August 2007, Chris Campbell wrote:
> >>>> On client I have:
> >>>>
> >>>> java.util.Map<String, Object> context =
> >>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
> >>>> context.put("username", "chris");
> >>>> context.put("password", "foobar");
> >>>>
> >>>> How do I access that context on the server side in my
> >>>> interceptor? I cannot seem to find where it is in the Message
> >>>> object, or am I horribly misunderstanding something?
> >>>
> >>> With those keys, they wouldn't get to the server. You would
> >>> need to use the BindingProvider.* keys.
> >>>
> >>> On the server side in an interceptor, you should be able to do:
> >>> AuthorizationPolicy policy =
> >>> message.get(AuthorizationPolicy.class);
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
Yes, http, and CXFServlet is running in Tomcat 5.5
Fred Dushin wrote:
> Just to be sure, are you using HTTP?
>
> Also, are you using the Jetty HTTP destination on the server side, or
> Tomcat?
>
> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
>
>> The AuthorizationPolicy is null in the server interceptor.
>>
>> Now my client does this
>>
>> BindingProvider bp = (BindingProvider)client;
>> java.util.Map<String, Object> context = bp.getRequestContext();
>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "foouser");
>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY, "foopass");
>>
>> My server interceptor does this (it is a Phase.USER_LOGICAL in
>> interceptor)
>>
>> // policy is always null here...
>> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
>> String username = policy.getUserName();
>> String password = policy.getPassword();
>>
>> Thanks.
>>
>> Daniel Kulp wrote:
>>> On Thursday 30 August 2007, Chris Campbell wrote:
>>>> On client I have:
>>>>
>>>> java.util.Map<String, Object> context =
>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>>> context.put("username", "chris");
>>>> context.put("password", "foobar");
>>>>
>>>> How do I access that context on the server side in my interceptor? I
>>>> cannot seem to find where it is in the Message object, or am I
>>>> horribly misunderstanding something?
>>>
>>> With those keys, they wouldn't get to the server. You would need to
>>> use the BindingProvider.* keys.
>>>
>>> On the server side in an interceptor, you should be able to do:
>>> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
>>>
>>>
>>
>
>
Re: basic auth question
Posted by Fred Dushin <fr...@dushin.net>.
Just to be sure, are you using HTTP?
Also, are you using the Jetty HTTP destination on the server side, or
Tomcat?
On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
> The AuthorizationPolicy is null in the server interceptor.
>
> Now my client does this
>
> BindingProvider bp = (BindingProvider)client;
> java.util.Map<String, Object> context = bp.getRequestContext();
> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
> "foouser");
> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
> "foopass");
>
> My server interceptor does this (it is a Phase.USER_LOGICAL in
> interceptor)
>
> // policy is always null here...
> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
> String username = policy.getUserName();
> String password = policy.getPassword();
>
> Thanks.
>
> Daniel Kulp wrote:
>> On Thursday 30 August 2007, Chris Campbell wrote:
>>> On client I have:
>>>
>>> java.util.Map<String, Object> context =
>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>> context.put("username", "chris");
>>> context.put("password", "foobar");
>>>
>>> How do I access that context on the server side in my interceptor? I
>>> cannot seem to find where it is in the Message object, or am I
>>> horribly misunderstanding something?
>>
>> With those keys, they wouldn't get to the server. You would
>> need to
>> use the BindingProvider.* keys.
>>
>> On the server side in an interceptor, you should be able to do:
>> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
>>
>>
>
Re: basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
The AuthorizationPolicy is null in the server interceptor.
Now my client does this
BindingProvider bp = (BindingProvider)client;
java.util.Map<String, Object> context = bp.getRequestContext();
context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "foouser");
context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY, "foopass");
My server interceptor does this (it is a Phase.USER_LOGICAL in
interceptor)
// policy is always null here...
AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
String username = policy.getUserName();
String password = policy.getPassword();
Thanks.
Daniel Kulp wrote:
> On Thursday 30 August 2007, Chris Campbell wrote:
>> On client I have:
>>
>> java.util.Map<String, Object> context =
>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>> context.put("username", "chris");
>> context.put("password", "foobar");
>>
>> How do I access that context on the server side in my interceptor? I
>> cannot seem to find where it is in the Message object, or am I
>> horribly misunderstanding something?
>
> With those keys, they wouldn't get to the server. You would need to
> use the BindingProvider.* keys.
>
> On the server side in an interceptor, you should be able to do:
> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
>
>
Re: basic auth question
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 30 August 2007, Chris Campbell wrote:
> On client I have:
>
> java.util.Map<String, Object> context =
> ((javax.xml.ws.BindingProvider)client).getRequestContext();
> context.put("username", "chris");
> context.put("password", "foobar");
>
> How do I access that context on the server side in my interceptor? I
> cannot seem to find where it is in the Message object, or am I
> horribly misunderstanding something?
With those keys, they wouldn't get to the server. You would need to
use the BindingProvider.* keys.
On the server side in an interceptor, you should be able to do:
AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
basic auth question
Posted by Chris Campbell <cc...@quaris.com>.
On client I have:
java.util.Map<String, Object> context =
((javax.xml.ws.BindingProvider)client).getRequestContext();
context.put("username", "chris");
context.put("password", "foobar");
How do I access that context on the server side in my interceptor? I
cannot seem to find where it is in the Message object, or am I
horribly misunderstanding something?
thanks
Chris
basic auth with JaxWsProxyFactoryBean
Posted by Chris Campbell <cc...@quaris.com>.
I want to setup basic auth, using an AuthInterceptor on the server
side, as discussed in another thread.
I am using JaxWsProxyFactoryBean on client side, simple frontend
style, but it is unclear to me how to put the AuthorizationPolicy
object into the request.
RE: Method level authentication?
Posted by Van Nguyen <vn...@ur.com>.
Thanks Dan.
I noticed that I was putting in the password twice... but upon changing
it.. AuthorizationPolicy is still null (the opName is working using your
workaround).
Here is a tcpdump:
POST /prototype_web/services/ProductSearchWebService HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Authorization: Basic dm5ndXllbjpibGFjaw==
SOAPAction: ""
Accept: *
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.5.0_04
Host: ur-vnguyen.wynnesystems.com:8888
Connection: keep-alive
Transfer-Encoding: chunked
1ca
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns1:g
etProductInformation xmlns:ns1="http://webservices.ur.com"><companyCode
xmlns:ns2="http://webservices.ur.com"></companyCode><itemNumber
xmlns:ns2="http://webservices.ur.com"></itemNumber><stockClass
xmlns:ns2="http://webservices.ur.com"></stockClass><countryCode
xmlns:ns2="http://webservices.ur.com"></countryCode></ns1:getProductInfo
rmation></soap:Body></soap:Envelope>
0
This is what my cxf.xml looks like for that endpoint:
><jaxws:endpoint id="productSearch"
>
implementor="com.ur.webservices.impl.ProductSearchImpl"
> address="/ProductSearchWebService">
> <jaxws:inInterceptors>
> <bean
class="com.ur.webservices.security.AuthorizationInterceptor"/>
> </jaxws:inInterceptors>
></jaxws:endpoint>
I am using the standard way of passing in the username/password now:
> BindingProvider bp = (BindingProvider)port;
> bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY,
"vnguyen");
> bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY,
"mypassword");
Thanks,
Van Nguyen
United Rentals, Inc
vnguyen@ur.com
(949) 225-6553
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Wednesday, August 29, 2007 8:45 AM
To: cxf-user@incubator.apache.org
Cc: Van Nguyen
Subject: Re: Method level authentication?
Van,
On Tuesday 28 August 2007, Daniel Kulp wrote:
> 2 parts:
> 1) Issue of opName being null - I just checked the RPCInInterceptor
> and it isn't setting a bunch of stuff that the DocLitInInterceptor is
> setting. WSDL_OPERATION is one that it's not setting. :-( I'll
> get those fixed tomorrow.
Fixed this on trunk. However, there is a workaround:
message.getExchange().get(OperationInfo.class) will get the
OperationInfo
object from which you can get the name.
> 2) AuthorizationPolicy is null - not sure on that one. That is
> provided but the transport if there is an Authorization header
> present. Is there anyway you can TCPdump/wireshare the raw request
> and see if there is an Authorization header? The code looks OK,
> although I must admit I've never done it that way. I've always used
> the standard JAX-WS API for setting the username/password for basic
> auth:
Figured this out. Your code is wrong:
> > policy.setPassword("vnguyen");
> > policy.setPassword("myPassword");
You're setting the password twice. Thus, no username is being set.
We
don't put any basic auth stuff on the wire unless there is a username.
Dan
>
> BindingProvider bp = (BindingProvider)port;
> bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "BJ");
> bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "pswd");
>
> Dan
>
> On Tuesday 28 August 2007, Van Nguyen wrote:
> > Dan,
> >
> > I'm giving this a shot and am having some difficulties with the
> > AuthorizationInterceptor finding the AuthorizationPolicy object.
> >
> > My Web Services looks something like this:
> >
> > @WebService(name = "productSearchService")
> > @SOAPBinding(style = Style.RPC, use = Use.LITERAL)
> > @WebFault(targetNamespace = "http://webservices.ur.com/types", name
> > = "productSearchException", faultBean =
> > "com.ur.webservices.webfaults.ProductSearchServiceFault")
> > @InInterceptors(interceptors={"com.ur.webservices.security.Authoriza
> >ti on Interceptor"})
> > public interface ProductSearch
> > {
> > public Item getItem(String itemNumber)
> > }
> >
> > Using the wsdl2java command, it created the java classes needed to
> > call this web service:
> >
> > ProductSearchImplService ss = new
> > ProductSearchImplService(wsdlURL, SERVICE_NAME);
> > ProductSearchService port = ss.getProductSearchImplPort();
> >
> > Client client = ClientProxy.getClient(port);
> > HTTPConduit httpConduit = (HTTPConduit)client.getConduit();
> > AuthorizationPolicy policy = new AuthorizationPolicy();
> > policy.setPassword("vnguyen");
> > policy.setPassword("myPassword");
> > httpConduit.setAuthorization(policy);
> >
> > Calling port.getItem("1234"), brings me into the
> > AuthorizationInterceptor... but both the AuthorizationPolicy and
> > opName are null - I also assumed you meant to write:
> > String opName = (String)message.get(Message.WSDL_OPERATION);
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Van Nguyen
> > United Rentals, Inc
> > vnguyen@ur.com
> > (949) 225-6553
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Tuesday, August 28, 2007 10:27 AM
> > To: cxf-user@incubator.apache.org
> > Cc: Van Nguyen
> > Subject: Re: Method level authentication?
> >
> >
> > Van,
> >
> > The answer is both yes and no.
> >
> > CXF doesn't have anything "built in" that would provide that
> > capability.
> >
> > However, it would be very easy to write an interceptor that would:
> >
> >
> > public class AuthorizationInterceptor extends
> > AbstractPhaseInterceptor<Message> {
> >
> > public AuthorizationInterceptor() {
> > super(Phase.USER_LOGICAL);
> > }
> >
> > public void handleMessage(Message message) throws Fault {
> > AuthorizationPolicy policy =
> > message.get(AuthorizationPolicy.class);
> > String opName = (String)message.put(Message.WSDL_OPERATION);
> >
> > //use username/passwords from AuthorizationPolicy to validate.
> > //Throw a fault or similar if processing should not
> > continue. }
> > }
> >
> >
> > There is also:
> > message.get(SecurityContext.class);
> > which can provide the principal object and checks for isUserInRole
> > if your deployment environment (tomcat/etc...) supports
> > configurations of users and roles on that level.
> >
> > Dan
> >
> > On Tuesday 28 August 2007, vannguyen0 wrote:
> > > Hi,
> > >
> > > I'm fairly new to webservices and was wondering if CXF has the
> > > ability to restrict users to certain web services methods. If I
> > > have PerformProductSearch and UpdateProductInformation, I want to
> > > allow user A (or users that is in user group A) permission to only
> > > PerformProductSearch. But user B (or users that are in user group
> > > B) can access to both methods.
> > >
> > > Thanks,
> > >
> > > Van
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Method level authentication?
Posted by Daniel Kulp <dk...@apache.org>.
Van,
On Tuesday 28 August 2007, Daniel Kulp wrote:
> 2 parts:
> 1) Issue of opName being null - I just checked the RPCInInterceptor
> and it isn't setting a bunch of stuff that the DocLitInInterceptor is
> setting. WSDL_OPERATION is one that it's not setting. :-( I'll
> get those fixed tomorrow.
Fixed this on trunk. However, there is a workaround:
message.getExchange().get(OperationInfo.class) will get the OperationInfo
object from which you can get the name.
> 2) AuthorizationPolicy is null - not sure on that one. That is
> provided but the transport if there is an Authorization header
> present. Is there anyway you can TCPdump/wireshare the raw request
> and see if there is an Authorization header? The code looks OK,
> although I must admit I've never done it that way. I've always used
> the standard JAX-WS API for setting the username/password for basic
> auth:
Figured this out. Your code is wrong:
> > policy.setPassword("vnguyen");
> > policy.setPassword("myPassword");
You're setting the password twice. Thus, no username is being set. We
don't put any basic auth stuff on the wire unless there is a username.
Dan
>
> BindingProvider bp = (BindingProvider)port;
> bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "BJ");
> bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "pswd");
>
> Dan
>
> On Tuesday 28 August 2007, Van Nguyen wrote:
> > Dan,
> >
> > I'm giving this a shot and am having some difficulties with the
> > AuthorizationInterceptor finding the AuthorizationPolicy object.
> >
> > My Web Services looks something like this:
> >
> > @WebService(name = "productSearchService")
> > @SOAPBinding(style = Style.RPC, use = Use.LITERAL)
> > @WebFault(targetNamespace = "http://webservices.ur.com/types", name
> > = "productSearchException", faultBean =
> > "com.ur.webservices.webfaults.ProductSearchServiceFault")
> > @InInterceptors(interceptors={"com.ur.webservices.security.Authoriza
> >ti on Interceptor"})
> > public interface ProductSearch
> > {
> > public Item getItem(String itemNumber)
> > }
> >
> > Using the wsdl2java command, it created the java classes needed to
> > call this web service:
> >
> > ProductSearchImplService ss = new
> > ProductSearchImplService(wsdlURL, SERVICE_NAME);
> > ProductSearchService port = ss.getProductSearchImplPort();
> >
> > Client client = ClientProxy.getClient(port);
> > HTTPConduit httpConduit = (HTTPConduit)client.getConduit();
> > AuthorizationPolicy policy = new AuthorizationPolicy();
> > policy.setPassword("vnguyen");
> > policy.setPassword("myPassword");
> > httpConduit.setAuthorization(policy);
> >
> > Calling port.getItem("1234"), brings me into the
> > AuthorizationInterceptor... but both the AuthorizationPolicy and
> > opName are null - I also assumed you meant to write:
> > String opName = (String)message.get(Message.WSDL_OPERATION);
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Van Nguyen
> > United Rentals, Inc
> > vnguyen@ur.com
> > (949) 225-6553
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Tuesday, August 28, 2007 10:27 AM
> > To: cxf-user@incubator.apache.org
> > Cc: Van Nguyen
> > Subject: Re: Method level authentication?
> >
> >
> > Van,
> >
> > The answer is both yes and no.
> >
> > CXF doesn't have anything "built in" that would provide that
> > capability.
> >
> > However, it would be very easy to write an interceptor that would:
> >
> >
> > public class AuthorizationInterceptor extends
> > AbstractPhaseInterceptor<Message> {
> >
> > public AuthorizationInterceptor() {
> > super(Phase.USER_LOGICAL);
> > }
> >
> > public void handleMessage(Message message) throws Fault {
> > AuthorizationPolicy policy =
> > message.get(AuthorizationPolicy.class);
> > String opName = (String)message.put(Message.WSDL_OPERATION);
> >
> > //use username/passwords from AuthorizationPolicy to validate.
> > //Throw a fault or similar if processing should not
> > continue. }
> > }
> >
> >
> > There is also:
> > message.get(SecurityContext.class);
> > which can provide the principal object and checks for isUserInRole
> > if your deployment environment (tomcat/etc...) supports
> > configurations of users and roles on that level.
> >
> > Dan
> >
> > On Tuesday 28 August 2007, vannguyen0 wrote:
> > > Hi,
> > >
> > > I'm fairly new to webservices and was wondering if CXF has the
> > > ability to restrict users to certain web services methods. If I
> > > have PerformProductSearch and UpdateProductInformation, I want to
> > > allow user A (or users that is in user group A) permission to only
> > > PerformProductSearch. But user B (or users that are in user group
> > > B) can access to both methods.
> > >
> > > Thanks,
> > >
> > > Van
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Method level authentication?
Posted by Daniel Kulp <dk...@apache.org>.
Van,
2 parts:
1) Issue of opName being null - I just checked the RPCInInterceptor and
it isn't setting a bunch of stuff that the DocLitInInterceptor is
setting. WSDL_OPERATION is one that it's not setting. :-( I'll get
those fixed tomorrow.
2) AuthorizationPolicy is null - not sure on that one. That is provided
but the transport if there is an Authorization header present. Is
there anyway you can TCPdump/wireshare the raw request and see if there
is an Authorization header? The code looks OK, although I must admit
I've never done it that way. I've always used the standard JAX-WS API
for setting the username/password for basic auth:
BindingProvider bp = (BindingProvider)port;
bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "BJ");
bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "pswd");
Dan
On Tuesday 28 August 2007, Van Nguyen wrote:
> Dan,
>
> I'm giving this a shot and am having some difficulties with the
> AuthorizationInterceptor finding the AuthorizationPolicy object.
>
> My Web Services looks something like this:
>
> @WebService(name = "productSearchService")
> @SOAPBinding(style = Style.RPC, use = Use.LITERAL)
> @WebFault(targetNamespace = "http://webservices.ur.com/types", name =
> "productSearchException", faultBean =
> "com.ur.webservices.webfaults.ProductSearchServiceFault")
> @InInterceptors(interceptors={"com.ur.webservices.security.Authorizati
>on Interceptor"})
> public interface ProductSearch
> {
> public Item getItem(String itemNumber)
> }
>
> Using the wsdl2java command, it created the java classes needed to
> call this web service:
>
> ProductSearchImplService ss = new
> ProductSearchImplService(wsdlURL, SERVICE_NAME);
> ProductSearchService port = ss.getProductSearchImplPort();
>
> Client client = ClientProxy.getClient(port);
> HTTPConduit httpConduit = (HTTPConduit)client.getConduit();
> AuthorizationPolicy policy = new AuthorizationPolicy();
> policy.setPassword("vnguyen");
> policy.setPassword("myPassword");
> httpConduit.setAuthorization(policy);
>
> Calling port.getItem("1234"), brings me into the
> AuthorizationInterceptor... but both the AuthorizationPolicy and
> opName are null - I also assumed you meant to write:
> String opName = (String)message.get(Message.WSDL_OPERATION);
>
> Any ideas?
>
> Thanks,
>
> Van Nguyen
> United Rentals, Inc
> vnguyen@ur.com
> (949) 225-6553
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Tuesday, August 28, 2007 10:27 AM
> To: cxf-user@incubator.apache.org
> Cc: Van Nguyen
> Subject: Re: Method level authentication?
>
>
> Van,
>
> The answer is both yes and no.
>
> CXF doesn't have anything "built in" that would provide that
> capability.
>
> However, it would be very easy to write an interceptor that would:
>
>
> public class AuthorizationInterceptor extends
> AbstractPhaseInterceptor<Message> {
>
> public AuthorizationInterceptor() {
> super(Phase.USER_LOGICAL);
> }
>
> public void handleMessage(Message message) throws Fault {
> AuthorizationPolicy policy =
> message.get(AuthorizationPolicy.class);
> String opName = (String)message.put(Message.WSDL_OPERATION);
>
> //use username/passwords from AuthorizationPolicy to validate.
> //Throw a fault or similar if processing should not continue.
> }
> }
>
>
> There is also:
> message.get(SecurityContext.class);
> which can provide the principal object and checks for isUserInRole if
> your deployment environment (tomcat/etc...) supports configurations of
> users and roles on that level.
>
> Dan
>
> On Tuesday 28 August 2007, vannguyen0 wrote:
> > Hi,
> >
> > I'm fairly new to webservices and was wondering if CXF has the
> > ability to restrict users to certain web services methods. If I
> > have PerformProductSearch and UpdateProductInformation, I want to
> > allow user A (or users that is in user group A) permission to only
> > PerformProductSearch. But user B (or users that are in user group B)
> > can access to both methods.
> >
> > Thanks,
> >
> > Van
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Method level authentication?
Posted by Van Nguyen <vn...@ur.com>.
Dan,
I'm giving this a shot and am having some difficulties with the
AuthorizationInterceptor finding the AuthorizationPolicy object.
My Web Services looks something like this:
@WebService(name = "productSearchService")
@SOAPBinding(style = Style.RPC, use = Use.LITERAL)
@WebFault(targetNamespace = "http://webservices.ur.com/types", name =
"productSearchException", faultBean =
"com.ur.webservices.webfaults.ProductSearchServiceFault")
@InInterceptors(interceptors={"com.ur.webservices.security.Authorization
Interceptor"})
public interface ProductSearch
{
public Item getItem(String itemNumber)
}
Using the wsdl2java command, it created the java classes needed to call
this web service:
ProductSearchImplService ss = new
ProductSearchImplService(wsdlURL, SERVICE_NAME);
ProductSearchService port = ss.getProductSearchImplPort();
Client client = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit)client.getConduit();
AuthorizationPolicy policy = new AuthorizationPolicy();
policy.setPassword("vnguyen");
policy.setPassword("myPassword");
httpConduit.setAuthorization(policy);
Calling port.getItem("1234"), brings me into the
AuthorizationInterceptor... but both the AuthorizationPolicy and opName
are null - I also assumed you meant to write:
String opName = (String)message.get(Message.WSDL_OPERATION);
Any ideas?
Thanks,
Van Nguyen
United Rentals, Inc
vnguyen@ur.com
(949) 225-6553
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Tuesday, August 28, 2007 10:27 AM
To: cxf-user@incubator.apache.org
Cc: Van Nguyen
Subject: Re: Method level authentication?
Van,
The answer is both yes and no.
CXF doesn't have anything "built in" that would provide that capability.
However, it would be very easy to write an interceptor that would:
public class AuthorizationInterceptor extends
AbstractPhaseInterceptor<Message> {
public AuthorizationInterceptor() {
super(Phase.USER_LOGICAL);
}
public void handleMessage(Message message) throws Fault {
AuthorizationPolicy policy =
message.get(AuthorizationPolicy.class);
String opName = (String)message.put(Message.WSDL_OPERATION);
//use username/passwords from AuthorizationPolicy to validate.
//Throw a fault or similar if processing should not continue.
}
}
There is also:
message.get(SecurityContext.class);
which can provide the principal object and checks for isUserInRole if
your deployment environment (tomcat/etc...) supports configurations of
users and roles on that level.
Dan
On Tuesday 28 August 2007, vannguyen0 wrote:
> Hi,
>
> I'm fairly new to webservices and was wondering if CXF has the ability
> to restrict users to certain web services methods. If I have
> PerformProductSearch and UpdateProductInformation, I want to allow
> user A (or users that is in user group A) permission to only
> PerformProductSearch. But user B (or users that are in user group B)
> can access to both methods.
>
> Thanks,
>
> Van
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Method level authentication?
Posted by mattmadhavan <ma...@yahoo.com>.
Hi there!
Looks like you may have a complete solution which many a folks are looking
for! Can you please post a complete (example) solution? It will be great if
you could do so!
Thanks
Matt
BigEHokie wrote:
>
> If you're using Spring and WSS4J, I'd also recommend looking at Acegi.
> We're using Acegi's method interceptor along with method level
> annotations to secure web services based on role and other custom
> granted authorities. It's a fairly easy solution once you WSS4J and
> Acegi hooked together.
>
> On Tue, 2007-08-28 at 13:26 -0400, Daniel Kulp wrote:
>
>> Van,
>>
>> The answer is both yes and no.
>>
>> CXF doesn't have anything "built in" that would provide that capability.
>> However, it would be very easy to write an interceptor that would:
>>
>>
>> public class AuthorizationInterceptor extends
>> AbstractPhaseInterceptor<Message> {
>>
>> public AuthorizationInterceptor() {
>> super(Phase.USER_LOGICAL);
>> }
>>
>> public void handleMessage(Message message) throws Fault {
>> AuthorizationPolicy policy =
>> message.get(AuthorizationPolicy.class);
>> String opName = (String)message.put(Message.WSDL_OPERATION);
>>
>> //use username/passwords from AuthorizationPolicy to validate.
>> //Throw a fault or similar if processing should not continue.
>> }
>> }
>>
>>
>> There is also:
>> message.get(SecurityContext.class);
>> which can provide the principal object and checks for isUserInRole if
>> your deployment environment (tomcat/etc...) supports configurations of
>> users and roles on that level.
>>
>> Dan
>>
>>
>> On Tuesday 28 August 2007, vannguyen0 wrote:
>> > Hi,
>> >
>> > I'm fairly new to webservices and was wondering if CXF has the ability
>> > to restrict users to certain web services methods. If I have
>> > PerformProductSearch and UpdateProductInformation, I want to allow
>> > user A (or users that is in user group A) permission to only
>> > PerformProductSearch. But user B (or users that are in user group B)
>> > can access to both methods.
>> >
>> > Thanks,
>> >
>> > Van
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Method-level-authentication--tf4342781.html#a13354095
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Method level authentication?
Posted by Eric Miles <er...@kronos.com>.
If you're using Spring and WSS4J, I'd also recommend looking at Acegi.
We're using Acegi's method interceptor along with method level
annotations to secure web services based on role and other custom
granted authorities. It's a fairly easy solution once you WSS4J and
Acegi hooked together.
On Tue, 2007-08-28 at 13:26 -0400, Daniel Kulp wrote:
> Van,
>
> The answer is both yes and no.
>
> CXF doesn't have anything "built in" that would provide that capability.
> However, it would be very easy to write an interceptor that would:
>
>
> public class AuthorizationInterceptor extends
> AbstractPhaseInterceptor<Message> {
>
> public AuthorizationInterceptor() {
> super(Phase.USER_LOGICAL);
> }
>
> public void handleMessage(Message message) throws Fault {
> AuthorizationPolicy policy =
> message.get(AuthorizationPolicy.class);
> String opName = (String)message.put(Message.WSDL_OPERATION);
>
> //use username/passwords from AuthorizationPolicy to validate.
> //Throw a fault or similar if processing should not continue.
> }
> }
>
>
> There is also:
> message.get(SecurityContext.class);
> which can provide the principal object and checks for isUserInRole if
> your deployment environment (tomcat/etc...) supports configurations of
> users and roles on that level.
>
> Dan
>
>
> On Tuesday 28 August 2007, vannguyen0 wrote:
> > Hi,
> >
> > I'm fairly new to webservices and was wondering if CXF has the ability
> > to restrict users to certain web services methods. If I have
> > PerformProductSearch and UpdateProductInformation, I want to allow
> > user A (or users that is in user group A) permission to only
> > PerformProductSearch. But user B (or users that are in user group B)
> > can access to both methods.
> >
> > Thanks,
> >
> > Van
>
>
>
Re: Method level authentication?
Posted by Daniel Kulp <dk...@apache.org>.
Van,
The answer is both yes and no.
CXF doesn't have anything "built in" that would provide that capability.
However, it would be very easy to write an interceptor that would:
public class AuthorizationInterceptor extends
AbstractPhaseInterceptor<Message> {
public AuthorizationInterceptor() {
super(Phase.USER_LOGICAL);
}
public void handleMessage(Message message) throws Fault {
AuthorizationPolicy policy =
message.get(AuthorizationPolicy.class);
String opName = (String)message.put(Message.WSDL_OPERATION);
//use username/passwords from AuthorizationPolicy to validate.
//Throw a fault or similar if processing should not continue.
}
}
There is also:
message.get(SecurityContext.class);
which can provide the principal object and checks for isUserInRole if
your deployment environment (tomcat/etc...) supports configurations of
users and roles on that level.
Dan
On Tuesday 28 August 2007, vannguyen0 wrote:
> Hi,
>
> I'm fairly new to webservices and was wondering if CXF has the ability
> to restrict users to certain web services methods. If I have
> PerformProductSearch and UpdateProductInformation, I want to allow
> user A (or users that is in user group A) permission to only
> PerformProductSearch. But user B (or users that are in user group B)
> can access to both methods.
>
> Thanks,
>
> Van
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog