Grouper Developers Forum

["Sanjay Vivek" <>]

Hi everyone,

>What security token formats does Axis2/Rampart support?

WS-Security supports 4 different actions: Timestamping, Authentication,
Encryption and Signature. Thus far, I have only worked with Timestamping
and Authentication. Timestamping is a good way of ensuring that the
Rampart module is engaged and was merely for testing purposes.
Authentication is based on a UsernameToken, and essentially consists of
a username and password. 

One minor obstacle in using Rampart is that Rampart has to be configured
on both the service and client side. To quote the Apache Rampart site:
"When securing a SOAP message, the sender must know the security actions
to be performed on the message and the receiver must know enough details
to process and validate the security of the message. Therefore when
using Rampart with Axis2, it must be engaged at both ends." 

This is not necessarily a problem for us since we plan on providing the
clients for our Grouper WS anyway. However, it is not inconceivable how
this might be a deterrent to using Rampart since all future clients have
to have a Rampart installation in place before working with a Grouper WS
protected by WS-Security.

We are contemplating placing the Rampart functionality in a proxy class
that talks to the Grouper web service class. In this way the Rampart
security functionality can be kept in a separate layer from the plain
web service code. This would hopefully enable other security techniques
to be deployed in a similar fashion. It should be noted we do not have a
fixed road map for this work. We are in the exploratory phase of looking
at what is possible and what is desirable. The general problem with web
services work we are finding is that while there is lots of information
on all the standards and techniques that *can* be used there is very
little information on actually practically using them and what the
implications are. The discussions and pointers on the list have been
very useful in helping us to understand the practicalities of this area.


Hopefully the proxy class approach detailed above will prove viable and
the rampart functionality can be deployed as a separate layer on top of
existing code rather than a hard integration into the plain web services
code. Thus allowing other techniques to be used. The main lesson we are
taking from the discussions so far is that many people (including us)
will want o authenticate web services in many different ways given their
different use cases and existing infrastructures. So having an approach
that allows for flexibility would be desirable.  

>I don't understand.  Perhaps you can explain this a bit more in your
planned followup?

I didn't explain this properly earlier because I didn't want to get into
intricacies of Rampart so I apologise. Basically, what I meant was that
we want to use WS-Security to check who authenticated against our
Grouper WS and whether the user has sufficient rights to perform a
certain action (add a user to a group for example). Currently, our
Grouper WS assumes each and every user is a member of the Wheel group
and can pretty much do anything. We haven't worked with Web Services
Security much and we're more familiar with HTTP authentication. However,
from what I've read and researched on the WS security, the WS Security
folk considers HTTP authentication obsolete and WS-Security is the
preferred method of authentication. 

We are aware that the counter argument that WS-Security is an
overcomplicated pile of junk also has some validity. However if it has
traction on the platforms/languages that we need to talk to(particularly
.NET and SAP)  then it is desirable for us to examine it and see if we
can practically use it

Regards
Sanjay