Grouper Developers Forum

["Paul B. Hill" <>]

Hi,

Do you have any pointers to documentation or design discussions that 
address the security model that you will be using for the web services?

Paul

Sanjay Vivek wrote:
> 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