You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Cameron Taggart <ca...@gmail.com> on 2007/01/25 00:52:00 UTC
common/best practices for SOAP authentication/authorization
Hi All, I've been surfing the web looking for common or best practices
for dealing with authentication and authorization with SOAP. If you
have some good links, please pass them along. A proposed solution
internally here was to simply send an a username and password and get
back a token. The tokens are kept in a cache and managed by the
application. Each subsequent SOAP call by a client requires the token
as a the first parameter. Is that good practice? It doesn't quite
feel right to me.
cheers,
Cameron
RE: common/best practices for SOAP authentication/authorization
Posted by Ted Neward <te...@tedneward.com>.
> There's also specs like WS-Security, WS-Authentication, etc...
>
Most of which, by the way, end up doing exactly what you just described
(including HTTP Basic Auth). The key is that the standards specify a way to
do auth with the details (the content of the token, different mechanisms
behind the token, and so on) understood ahead of time.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> -----Original Message-----
> From: Daniel Kulp [mailto:daniel.kulp@iona.com]
> Sent: Monday, January 29, 2007 10:35 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: common/best practices for SOAP authentication/authorization
>
> On Wednesday 24 January 2007 18:52, Cameron Taggart wrote:
> > Hi All, I've been surfing the web looking for common or best practices
> > for dealing with authentication and authorization with SOAP. If you
> > have some good links, please pass them along. A proposed solution
> > internally here was to simply send an a username and password and get
> > back a token. The tokens are kept in a cache and managed by the
> > application. Each subsequent SOAP call by a client requires the token
> > as a the first parameter. Is that good practice? It doesn't quite
> > feel right to me.
>
>
> This is a topic where if you ask 10 different people, you're likely to get
> 11
> different responses. :-) What's best for one application may not be
> the
> best option for all applications.
>
> What you described would work fine. The issue some people have with that
> is
> that it requires the wsdl contract to specify the authorization mechanism.
> Some people would be all up in arms about that.
>
> If you're using HTTP as the transport, the easiest thing might be to just
> use
> HTTP basic auth. The JAXWS clients have properties to set the
> username/password on the client itself. All calls using the client will
> then
> send the basic auth tokens which you can then retrieve on the server side.
> The main issue is that it's kind of HTTP only. Basic auth isn't actually
> the most secure either.
>
> You could also write a handler/interceptor that would put/pull the
> information
> in the SOAP headers and validates it. Thus, the operations in the WSDL
> wouldn't contain the authentication mechanisms.
>
> There's also specs like WS-Security, WS-Authentication, etc...
>
> There are a bunch more options. It really just depends on what "feels"
> right
> for you.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
> 2:49 PM
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
2:49 PM
Re: common/best practices for SOAP authentication/authorization
Posted by Daniel Kulp <da...@iona.com>.
On Wednesday 24 January 2007 18:52, Cameron Taggart wrote:
> Hi All, I've been surfing the web looking for common or best practices
> for dealing with authentication and authorization with SOAP. If you
> have some good links, please pass them along. A proposed solution
> internally here was to simply send an a username and password and get
> back a token. The tokens are kept in a cache and managed by the
> application. Each subsequent SOAP call by a client requires the token
> as a the first parameter. Is that good practice? It doesn't quite
> feel right to me.
This is a topic where if you ask 10 different people, you're likely to get 11
different responses. :-) What's best for one application may not be the
best option for all applications.
What you described would work fine. The issue some people have with that is
that it requires the wsdl contract to specify the authorization mechanism.
Some people would be all up in arms about that.
If you're using HTTP as the transport, the easiest thing might be to just use
HTTP basic auth. The JAXWS clients have properties to set the
username/password on the client itself. All calls using the client will then
send the basic auth tokens which you can then retrieve on the server side.
The main issue is that it's kind of HTTP only. Basic auth isn't actually
the most secure either.
You could also write a handler/interceptor that would put/pull the information
in the SOAP headers and validates it. Thus, the operations in the WSDL
wouldn't contain the authentication mechanisms.
There's also specs like WS-Security, WS-Authentication, etc...
There are a bunch more options. It really just depends on what "feels" right
for you.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com