So you are a happy Apache CXF developer working with its second-to-none WS SOAP front-end, creating SOAP endpoints protected by WS-Security. Your friends from the other team have deployed few CXF JAX-RS endpoints protected by the OAuth2 filter validating the incoming OAuth2 tokens with the remote OAuth2 server.
Now, you really, really, really want to get your SOAP client code use OAuth2 tokens too, the same tokens non-SOAP RS clients use to access RS endpoints, because it is something new to try.
So how complex can it be ? The answer: it is a child's play with Apache CXF. Follow these steps:
- Get CXF WS client code use WS-Security Binary Token mechanism as a transport for passing OAuth2 Bearer tokens to the server - easy
- If you work with WS-Policy, add one more WS-Policy alternative allowing for WS-Security Binary Tokens, in addition to the existing security alternatives, no code changes
- Add a basic OAuthRequestInterceptor extension immediately after CXF WSS4JInInterceptor which will make the extracted binary token available on the current message. All this custom interceptor will do is get the token from the message and pass it over to the super-class as suggested in the commented code.
- Make sure your OAuthRequestInterceptor does not interfere with other WS-Security authentication mechanisms if they are supported - if it is non a binary token then simply let the request continue
"Now you are talking", I can hear you saying. Give it a try please, and tell your friends from the other team how easy it was for you to join the OAuth2 game.
Friday, February 7, 2014
Subscribe to:
Post Comments (Atom)
2 comments:
old post but i'm struggling with the ws-policy definition. The ws-security spec allows the specification of various token types e.g kerberos, x509 etc but not an oauth token. There doesn't appear to be a generic binary token element either?
Can you please ask at CXF users list ? Thanks
Post a Comment