grouper-dev - Re: [grouper-dev] Update on Rampart authentication.
Subject: Grouper Developers Forum
List archive
- From: "Tom Scavo" <>
- To: "Tom Barton" <>
- Cc: "Sanjay Vivek" <>, "Grouper Dev" <>
- Subject: Re: [grouper-dev] Update on Rampart authentication.
- Date: Mon, 4 Feb 2008 15:55:57 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jXGDN15I2JjdyShBFOQnloBdyG98YyJbEv5UQxdR2FLo3RKLUbhiGt2sWdrEy6qnZaIKOd0U3He/3fpMnRxiBw3ZvcPW1xroNNbtvGdSEBG9ARFXRIGN0x4/KX3jigD00qs6SVzURwpO3xM5cBvNLNqZ3meCE8uj2/ZxOZDZvAY=
Thanks, Tom---I had the same question. Does Rampart support the X.509
Token Profile, for instance? Also, what version (precisely) of
WS-Security is supported?
Thanks,
Tom
On Feb 4, 2008 3:33 PM, Tom Barton
<>
wrote:
> Thanks very much, Sanjay. Do you know whether/how rampart handles the
> other WS-Security token formats (Kerberos, SAML, X.509)?
>
> Tom
>
>
> Sanjay Vivek wrote:
> > 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
>
- Update on Rampart authentication., Sanjay Vivek, 02/04/2008
- Re: [grouper-dev] Update on Rampart authentication., Tom Barton, 02/04/2008
- Re: [grouper-dev] Update on Rampart authentication., Tom Scavo, 02/04/2008
- RE: [grouper-dev] Update on Rampart authentication., Sanjay Vivek, 02/05/2008
- Re: [grouper-dev] Update on Rampart authentication., Tom Barton, 02/04/2008
Archive powered by MHonArc 2.6.16.