Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper & Web Services

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper & Web Services

Chronological Thread 
  • From: "RL 'Bob' Morgan" <>
  • To: Grouper Dev <>
  • Subject: Re: [grouper-dev] Grouper & Web Services
  • Date: Mon, 26 Nov 2007 12:50:04 -0800 (PST)

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

In terms of functionality, as a principle at least all the functionality used by the current local UI should be available via protocol. That is, there should be no barrier to implementing a rich, complete UI via the protocol interface. I suppose the same would apply to import/export tools.

In terms of protocols, at UW there has been a grassroots web services activity (see , though unfortunately most innaresting stuff is IP-addr-protected) that has been focusing almost excusively on REST (or ROA as the buzzphrase goes) interfaces. Not wanting to get into REST vs WS-*, let me just say REST would definitely be our preference.

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

REST preferred, as I mentioned. If SOAP is to be supported it would be important IMHO to clarify a development plan (eg write WSDL based on current APIs, import into various identified SOAP toolkits, test with various client languages etc) to make sure we're on the same page regarding methodology and benefits.

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

People are writing support for REST interfaces in Java, Perl, Ruby, etc.

The instances of WS-* interfaces I'm aware of have been MS tools on the server side, and MS and homegrown on the client side.

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

(Just for clarity, people usually use "WS" to mean WS-*, ie SOAP+WSDL+etc. If you mean to be agnostic about this, "-ws" might indicate this.)

As much as possible it would be good, as with browser interfaces, for Grouper to leave authentication to the container. In our case we promote mutual authentication with certs for our REST interfaces (the only WS-* interfaces I'm aware of are using username/password), where the authenticating parties are processes, not end users.

This kind of access of course brings up the n-tier authentication issue (or set of issues perhaps). Meaning mostly: does the application deal in user-based access control, meaning the client application has to communicate the user on behalf of which it is requesting operations; or does it deal with process-based access control, meaning client processes are just identified as themselves; or a combination of the two? This is difficult stuff, and will likely vary a lot from site to site.

I have a feeling that one useful mode will be where protocol access mimics as closely as possible the way the current UI works, ie user-based, and the security machinery is expected to deliver the verified user to the app just as it does now. There may be another useful mode where processes-as-processes do protocol access, with controls applied to what they can do; it would be nice if the current user-based controls can just cover that, but it would need to be demonstrated.

- RL "Bob"

Archive powered by MHonArc 2.6.16.

Top of Page