Grouper Developers Forum

["Stephen M. Barrett" <>]

Chris Hyzer wrote:

Gary, thanks for organizing.  Here are responses from Penn, and I will be on the call on Wed.

  

1. what forms of "web services interface" ought to be in the core product
in, say, the next 1 year?
    

You mean SOAP vs. REST?  Or which operations?  We would like SOAP and simple operations like add/edit groups, add/remove members (individually or in batch)
  

list/add/remove members.  add/remove accepting arrays of user identities would facilitate batch.

2. should SOAP be supported by the first WS-capable release (which *might*
also have additional capabilities)?
    

Yes
  

SOAP.  I'll admit that I've not yet delved into REST as deeply as I should but I will in the near future.

3. what tools are most commonly used on campuses to create WS instances and
their clients?
    

We use Axis SOAP, and handcoded REST (but prefer Axis since it does a lot of code generation)
  

Axis SOAP.  .jws on the server side and generate stubs on the client side via Axis wsdl2java class.

We are heavy into Coldfusion these days.  CF uses Axis wsdl2java to generate its stubs when you want to invoke WS; it almost always works.  When the CF/Axis WS solution fails it is never the fault of Axis - Coldfusion's class loading architecture prevents developers from pre-loading classes generated by the wsdl2java class.  I believe Adobe is correcting this annoyance.

4. what grouper-WS authentication and access control requirements do
campuses have?
    

Our central authentication system does not currently support apps (only people), so anything is fine that has usernames/passwords.  E.g. let the app server or web server do http simple-auth.  However, we would like to be able to lock down a user with a source IP address or subnet.  Perhaps a table and maintenance screen that matches up a username with a source IP addresses or subnet
  

Ideally you would want to be able to use WS-Security as the primary mechanism but that can be built in later.  Both the webserver (Apache, IIS...) and standard tomcat authentication mechanisms should be honored.  I would suggest that simply allowing the HTTPServletRequest.getRemoteUser() to be the authoritative username would suffice but I know that will not be enough.  Because of that I would suggest that 1) authentication be ignored in favor of suggesting that filters be employed at the tomcat request level or 2) an authentication interface be devised  (if one does not already exist) which can be implemented locally to apply additional verification requirements.

Thanks,
Chris

  

I am the one who pushes this at Cornell so I will be present at this weeks conference call.

begin:vcard
fn:Stephen Barrett
n:Barrett;Stephen
org:Cornell University;CIT/IS
adr;dom:;;120 Maple Ave;Ithaca;NY;14850
email;internet:
title:Tech Lead
tel;work:607.254.2917
tel;home:607.426.2759
note;quoted-printable:- Interpretation of content contained within this email is an opinion oft=
	he reader who acknowledges such through the action of viewing this messag=
	e.=0D=0A=
	
x-mozilla-html:FALSE
url:http://www.cornell.edu
version:2.1
end:vcard