Grouper Developers Forum

["Stephen A. Langella" <>]

I should mention with the release of Grid Grouper 1.1 you no longer need
to download caGrid and all 55 sub projects, you can download the Grid
Grouper source as its own project:

http://www.cagrid.org/mwiki/index.php?title=GridGrouper:Software:1.1

Under Grid Grouper 1.1 click "source code".



--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: Stephen M. Barrett 
[mailto:]
 
Sent: Tuesday, November 20, 2007 9:05 AM
To: 

Subject: Re: [grouper-dev] Grouper and Web Services.


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
>