Grouper Developers Forum

["Sanjay Vivek" <>]

Hi everyone,

This is a quick overview on how we went about incorporating Rampart into
our Grouper WS. At the moment, we have our own Grouper WS in place
although we'll be incorporating the official (future) Grouper WS once
its completed. A more complete guide to installing and configuring
Rampart will be provided soon. This email briefly explains the Rampart
architecture, the best way of securing services and clients, and how
Rampart was incorporated with Grouper WS.

As mentioned in an earlier email, WS-Security is the preferred method of
WS authentication. Although HTTP authentication can still be used, it is
considered obsolete by the WS folk. Rampart in turn is an Axis2 module
that implements WS-Security functionality. WS-Security supports 4
different actions: Timestamping, Authentication, Encryption and
Signature. At the moment, we're only concerned with Authentication.
Authentication is based on a UsernameToken, and consists of a username
and password. 

There are two different configuration approaches to Rampart: the
parameter based approach and policy based approach. However, after
working with Rampart, I'm not entirely sure why and when the parameter
based approach is used. It is extremely rigid in its implementation and
incorporates more of a static configuration approach. The client's
username/password has to be hardcoded on the client side, and you need a
different config file for each possible client. It was only after
delving deep into the parameter based approach that I realised this (and
after much Q&A in the Rampart mailing list). So if you do plan on
incorporating Rampart in the future, the policy based approach is the
way to go. It enables a dynamic approach to configuring client based
options. 

Rampart has to be engaged both on the service and client side. What this
really means is that the rampart-1.3.mar and addressing-1.1.mar files
have to be added to both the service and client installations. Rampart
also implements the java.auth.CallbackHandler interface to set/retrieve
the username/password of a particular user. This class might access an
LDAP directory or use other methods for associating a username with a
password, but thus far we have a simple callback class that returns
arbitrary values as a proof-of-concept. The callback class keeps the
actual service and authentication method separate. The service doesn't
need to know how the user was authenticated. The callback class
implements the authentication method and it is upto the developer to
implement this class. This is a light-weight intergration and as such,
very little code needs to be integrated into the Grouper WS.

Rampart can also extract the results of security processing at any state
of the execution flow. The UsernameToken information can be extracted at
the service side in a similar manner to REMOTE-USER (with HTTP
authentication). This is especially useful when deciding if a Grouper
user is authorised to perform a certain task ( for example, if he can
add/delete users to/from a group). 

So in brief, Rampart can be used to secure Grouper Web Services without
too much difficulty. The different configuration approaches to setting
up services and clients was initially confusing because there's not that
much material on the topic. However, it was fairly straightforward to
implement dynamic client/service configuration with the policy based
approach. 

Pls do feel free to contact me if you wish to know more about Rampart or
if you have any questions regarding the topic. Cheers. 


Regards
--------------
Sanjay Vivek
Web Analyst
Middleware Team
ISS
University of Newcastle Upon Tyne