Grouper Developers Forum

["RL 'Bob' Morgan" <>]

> 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 http://webservices.washington.edu/ , 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"