Grouper Developers Forum

["Sanjay Vivek" <>]

Hi all,

The documentation that comes with Grouper WS very clearly describes how
to deploy either Basic Auth or Rampart so there's no concern at all
about the documentation. It's just that we have been looking into adding
extra security functionality for our Web Services for a while now. Most
of our services had Basic Auth as a security mechanism and this was
something we wanted to expand on. Basic Auth is a very practical and
familiar way of adding security functionality to a WS and our developers
will always insist on it even in the current WS-Security climate. We
were looking into adding Token Assertion (in the form of UsernameToken)
and also Encryption for some of our services so we essentially required
3 security mechanisms: Basic Auth, UsernameToken and Encryption.
Although the easiest way of doing is deploying the service thrice but
with a different security mechanism for each deployment, this however
appeared rather unwieldy. 

We wanted a service with multiple security mechanisms in place and not
worry about the client side. The various depts in Newcastle require
different security mechanisms and so it would be practical to deploy a
service once and just add a different security mechanism when required.
We came across 2 options, policy alternatives and multiport WS. Policy
alternatives was a no go because its not implemented by Rampart or any
other WS implementation stack for that matter. Multiport WS proved
difficult to implement because it appears not much work is done on it
and we couldn't get help or replies from the various WS mailing lists. 

We believe our work done with respect to multiple security mechanisms is
relevant to Grouper WS and is the primary reason why we published an
extra report. We published the report because we needed an historical
archive of the work we had done. Cheers.

Regards
Sanjay 

>-----Original Message-----
>From: Tom Barton 
>[mailto:]
> 
>Sent: 14 May 2008 16:58
>To: Chris Hyzer
>Cc: caleb racey; Grouper Dev
>Subject: Re: [grouper-dev] Grouper design call, Wednesday, 14 
>May 2008, 1200EDT (1600Z)
>
>If I recall correctly, the "missing doc" would address what is 
>anticipated to be a common need, not necessarily to detail all 
>of the ways grouper-ws might be protected. I suppose, though, 
>that the former can be the start of a larger and evolving doc 
>of the latter.
>
>For comparison, cf. 
><https://wiki.internet2.edu/confluence/display/GrouperWG/Prereq
>uisites>.
>
>Tom
>
>Chris Hyzer wrote:
>> I think the issue is that the web.xml ships with servlet 
>container simple auth in it, right Tom?
>> I modified the README.txt to tell people to take out that 
>part in the web.xml if they don't want it (maybe it should be 
>a web.example.xml)...  Incidentally, we will use the kerberos 
>authenticator at Penn, so Im ok with commenting out the simple 
>auth as a default...  it's the easiest for a quick start 
>though probably.
>> 
>> Also, I found the same results as Sanjay, and the build 
>script reflects that.  You can either build grouper-ws in 
>non-rampart mode, or rampart mode (and you should deploy twice 
>to run both).  If you wanted container simple auth, and apache 
>+ mod_jk (or whatever connector to a servlet container), you 
>could do that in one deployment I believe...  same with 
>Kerberos.  But the rampart affects the Axis config files, and 
>you cant have multiple configs for multiple servlets in one webapp.
>> 
>> Regards,
>> Chris
>> 
>>> -----Original Message-----
>>> From: caleb racey 
>>> [mailto:]
>>> Sent: Wednesday, May 14, 2008 10:59 AM
>>> To: Grouper Dev
>>> Subject: RE: [grouper-dev] Grouper design call, Wednesday, 14 May 
>>> 2008, 1200EDT (1600Z)
>>>
>>>>    . protecting grouper-ws with apache + mod_proxy_ajp
>>>
>>> We have just published sanjay's report on his investigations of 
>>> various techniques for authenticating webservices  linked to from 
>>> http://gfivo.ncl.ac.uk/resources.php
>>>
>>>
>>> The 10 second summary is: There are theoretical techniques for 
>>> deploying a webservice once and using different auth routes 
>(multiple 
>>> policy, or multiple port), however the reality is that they are 
>>> poorly supported.
>>> Deploying the same webservice app twice and deploying 
>different auth 
>>> on top of each is much easier and works.
>>>
>>>
>>> Cheers
>>>
>>> Cal
>>>
>>> --------------------
>>> Caleb Racey
>>> Team Leader
>>> Middleware Team
>>> ISS
>>> Newcastle University
>>> --------------------
>