Grouper Developers Forum

["Stephen M. Barrett" <>]

The enormity of many of the open source projects today is bewildering.  
I too have been plunged into working with packages which are comprised 
of numerous projects.  I could speak for quite a while on just this 
subject but I wanted to weigh in on Web Services.

We too had need for process level access to the GrouperAPI.  Fortunately 
we had most of the pieces in place.  We have a single sign-on 
architecture that also allows process to process authentication.  Our 
SSO solution also contains features beyond process to process 
authentication to optionally proxy as the calling identity.  We have 
successfully used this architecture for Web Service authentication for 
the past few years; HTTP and SSL are transport layer requirements for 
Web Services in our environment.  We rely on the standard HTTP 
Authorization request header and not any form of WS-Security embedded in 
the WS (only because none of that was available when we started).

Exposing the GrouperAPI as a WS was really not that difficult for us.  
We simply installed Axis in our GrouperUI webapp, created a class which 
invoked the GrouperAPI and extended that class via a .jws file.  By 
front-ending the GrouperAPI with our own class we could easily guarantee 
that only basic types were used as parameters so as not to breach the 
language/environment independence barrier.

This is, in fact, something that I have found can be a very common 
solution for enabling existing webapps for process to process 
communications.  This approach, along with MVC concepts, allows for 
applications to be written which can easily server both human and 
non-human demands.

I have a concern about Axis2 which, I believe, uses the Apache 
HTTPClient package for that transport protocol.  The HTTPClient package 
will only allow preemptive credentials passing using the HTTP 
Authorization request header if the type is of "Basic"; which appears to 
be a protocol restriction imposed by that package.  This poses a problem 
for us as we are not using a type of "Basic" and are relying on 
preemptive credentials passing.  The HTTPClient package will only pass 
credentials for types other than "Basic" if it receives a challenge from 
the server.  I do believe our solution can work in the challenge scheme 
but it will set us back into separate paths for users and processes.  We 
will deal with that.

I would very much like a standard WS approach developed for Grouper 
which is delivered as part of the standard offering.  SOAP would be 
preferred but REST is here and we need to be conscious of it so both 
would probably find use. 

For my next part, I am probably going to explore some type of 
Grouper/WS/SAML functionality.  We have discovered needs for authN/Z on 
our Google Search Appliance.


caleb racey wrote:
> We have had a look at grid grouper and downloaded from cvs.
> Unfortunately the code base is large, it is a 514 meg  download  and
> there are 55 projects in the projects directory. A tour of the code
> directories have left us  somewhat bewildered with where to start and
> what parts of the functionality exist where. 
>
> I'm not even sure of the security model,  Am I correct in assuming the
> grouper web services bit of it is secured by the "Dorian - Proxy
> certificate Creation" model or is it just pki on setup?
>
> We have no desire to reinvent the wheel and if we thought we could use
> the caGrid code we would jump at the chance, but the complexity and size
> of the project is a large barrier to us. 
>
> If you have any pointers on where the grouper web services code exists
> in the project we will have another look.
>
>
> Regards
>
> Caleb Racey 
> Team Leader
> Middleware Team 
> ISS
> Newcastle University
>
>  
>
>  >-----Original Message-----
>  >From: Stephen A. Langella 
> [mailto:]
>  >Sent: 19 November 2007 19:06
>  >To: Chris Hyzer; Sanjay Vivek; 
>
>  >Subject: RE: [grouper-dev] Grouper and Web Services.
>  >
>  >I suggest you also take a look at Grid Grouper.  Grid Grouper is a web
>  >service implementation for Grouper built for Grid Computing.
> Depending
>  >on the web service security model you want, Grid Grouper may suit your
>  >needs.   For more information please take a look at:
>  >
>  >http://www.cagrid.org/mwiki/index.php?title=GridGrouper:Main
>  >
>  >--Steve
>  >
>  >Stephen Langella
>  >co-Director
>  >Software Research Institute
>  >Department of Biomedical Informatics
>  >Ohio State University
>  >
>  >Office: (614) 292-1065
>  >Lab: (614) 292-9845
>  
> >
>  >
>  >-----Original Message-----
>  >From: Chris Hyzer 
> [mailto:]
>  >Sent: Monday, November 19, 2007 1:58 PM
>  >To: Sanjay Vivek; 
>
>  >Subject: RE: [grouper-dev] Grouper and Web Services.
>  >
>  >I agree that SOAP is a good place to start, and it is nice that Axis2
>  >has a way to also expose the same service with REST.  There is this
> new
>  >project which does both automatically:
>  >
>  >http://xins.sourceforge.net/
>  >
>  >But it is new, and therefore risky.  Axis2 obviously has respectable
>  >momentum, and appears to me to be the best choice.
>  >
>  >What is your schedule for development and deployment?
>  >
>  >Regarding the search engine... maybe instead of circumventing the
>  >grouper api to use a search engine, maybe the grouper api could use a
>  >search engine internally...
>  >
>  >Kind regards,
>  >Chris
>  >
>  >
>  >-----Original Message-----
>  >From: Sanjay Vivek 
> [mailto:]
>  >Sent: Monday, November 19, 2007 11:53 AM
>  >To: 
>
>  >Subject: [grouper-dev] Grouper and Web Services.
>  >
>  >Hi folks at Tom Burton's request we (the gFIVO project from Newcastle
>  >University) are writing to update the list about our ideas for Web
>  >Services (WS) interfaces for grouper.
>  >
>  >We are looking at implementing web services interface to some of the
>  >grouper API.  One of the main reasons we're opting for a WS approach
> is
>  >because the current Grouper interface is fairly complex to someone who
>  >is not familiar to Grouper terminology. The usage of Stems, Subjects,
>  >data sources, and composite groups would probably intimidate most
>  >non-technical users (i.e a research group leader). Although it's
>  >entirely possible to implement a simpler interface by configuring the
>  >Grouper UI code, we would like to do so instead by going for a WS
>  >approach as we plan to implement more WS in the near future, and
> working
>  >with Grouper would be a good start.   Many of our development staff
> are
>  >much more comfortable with php so having an easy interface to grouper
>  >that they can use would be highly desirable. This should enable us to
>  >create simple  bespoke applications that manage group information in a
>  >given application  by talking to grouper via web services.
>  >
>  >We are deliberately starting in a small unambitious way with simple
>  >functions like:
>  >
>  >1) Find a Subject
>  >2) Add/Delete Subject to a Group
>  >3) List the Groups a Subject belongs to
>  >4) List a group's subjects
>  >
>  >This is so we can prove the concept and start with simple integration.
>  >We hope that the approach will be successful and we can expand it out
> to
>  >include more of the power of the grouper API.
>  >
>  >Ideally find a subject might not access the grouper api but instead
> will
>  >find subjects via a search engine. Experience has shown us that
> ldap/sql
>  >based searching for users is not ideal and the fuzzy matching,
>  >simplicity for the user, awareness of synonyms (e.g. bob, rob, Robert
>  >are same thing) allowed by  search engine based interfaces would be
>  >desirable. However that is for a future development initially we will
> go
>  >via the grouper API.
>  >
>  >We see this work as complementary to the existing grouper UI, we have
>  >deployed the grouper ui as a "power tool" for systems administrators
> to
>  >use. The php applications operating by web services we see as being
> used
>  >for simple use cases like  user self registration, moderated
>  >registration
>  >etc.
>  >
>  >Our choice of toolkit is Axis2 largely because it seems to have the
>  >largest mind share of web service frameworks, has reasonable tool
>  >support and supports REST style interfaces. We had a quick look at the
>  >grid grouper code base to see if we could use any of it but quickly
> got
>  >swamped in the 500meg worth of files. Without a guided tour of the
>  >codebase we think it would probably cost us more time to extricate the
>  >web services code than to implement ourselves.
>  >
>  >At the moment, we have opted for a SOAP based WS instead of a REST
> based
>  >WS. We decided on a SOAP approach merely because there's more toolkits
>  >available for SOAP WS. Apache Axis 2 supports both REST and SOAP WS so
> a
>  >REST client can easily invoke a SOAP WS and vice versa. We are
> building
>  >our WS primarily around SOAP, however we are strongly considering
>  >providing a REST service that complements SOAP as REST services are
>  >inherently less complex than SOAP because they naturally latch on to
>  >HTTP (GET, POST, PUT & DELETE) and can return XML, JSON etc as the
>  >response. And since the methods we're exposing as Web Services do not
>  >consist of complex data types, it is fairly straightforward to develop
>  >these Web Services with Eclipse (with the Web Tools Platform (WPT)
>  >plugin).
>  >
>  >
>  >Regards
>  >--------------
>  >Sanjay Vivek
>  >Middleware Team
>  >ISS
>  >University of Newcastle Upon Tyne
>   

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