Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Query on Response From Web Services Call

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Query on Response From Web Services Call

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "Mailvaganam, Hari" <>, Lichten Stein <>, "" <>
  • Subject: RE: [grouper-users] Query on Response From Web Services Call
  • Date: Mon, 17 May 2010 15:21:47 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

1) auth.setUsername - user name for the Grouper Web Services client (is
there any special privileges to grant to the account in the Grouper System?
Using an entity type 'application' account)

You need to decide how to authenticate the web service clients. The easiest
is just doing servlet container authentication (tomcat-users.xml), or maybe
apache authentication. If you run Kerberos, you could generate service
principals for the username, and GrouperWS will authenticate the user/pass
against Kerberos (if configured). Note, this username must be resolvable as
a subject in the system. I.e. you need this in a database table or ldap or
some custom source.

2) auth.setPassword - password for above account


3) setActAsSubjectId - ?
4) setActAsSubjectIdentifier - ?
5) setActAsSubjectSourceId - ?

Generally you run the web services as the user connecting, or the user
connecting acts as someone else. To act as someone else you need to specify
the id or identifier (and optionally the sourceId). Also, the connecting
user needs rights to do this in the

6) setClientVersion - the version of the Grouper Web Services client; e.g.

This is the version you are developing against. Generally when you start
developing, just put the current version of the server.

7) setGroupName - the group name that the membership look-up is being
performed (obtained from the grouper system)
8) setGroupUuid - the group UUID that the membership look-up is being
performed (obtained from the grouper system); can membership look-up be
performed if only 'setGroupUuid' is filled and not 'setGroupName'?

Yes, these are mutually exclusive. Generally you will use groupName and not
ID unless you are dereferencing a reference from a previous call perhaps

9) setSubjectId - ID of the member?
10) setSubjectIdentifier - ?
11) setSubjectSourceId - ?

This is how to refer to the user you are wondering if they are a member. The
ID is a non changing ID, at Penn we use PennId, e.g. 12345678. Identifier is
another way in your source you configure being able to refer to a person. At
Penn we use PennName, e.g. mchyzer. If you know the sourceId, you should
fill that in (from sources.xml), if you fill it in the call is better
performing (so all sources aren't queried), and if there are conflicts (same
subjectIdentifier in multiple sources), an exception will not the thrown.


Archive powered by MHonArc 2.6.16.

Top of Page