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 16:47:01 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

There is a group in which can restrict who is allowed
to connect to web services:

# If there is an entry here for group name, then all web service client users
must be in this group (before the actAs) = etc:webServiceClientUsers

If you comment that out maybe you will be allowed, or add group, and assign
the user to that group through GSH.

Take a look here, it goes through some of this bootstrap stuff...


-----Original Message-----
From: Mailvaganam, Hari

Sent: Monday, May 17, 2010 4:33 PM
To: Chris Hyzer; Lichten Stein;

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

Hi Chris:

Thank you very much for the detailed explanation.

When I ran the class 'WsSampleHasMemberLite' as a java application, the
following exception was caught:

"memberFilter: All, actAsSubject: WsSubjectLookup[subjectId=], fieldName:
null, includeGroupDetail: false, includeSubjectDetail: false,
subjectAttributeNames: null
,params: null
, java.lang.RuntimeException: User is not authorized
Caused by: edu.internet2.middleware.grouper.exception.GroupNotFoundException:
Cannot find group with name: 'etc:webServiceClientUsers'"

The WsSampleHasMemberLite web services search was run with a different group
name than the value caught in above exception.

I searched the 'grouper-ws_v1_3' project for 'etc:webServiceClientUsers'; it
is listed in two files (line commented out in both files):


2) grouper-ws_v1.3/resources/

Any ideas on why the above exception is caught, although the
'WsSampleHasMemberLite' search, has setGroupName with a different value?


Best regards,


-----Original Message-----
From: Chris Hyzer

Sent: May 17, 2010 12:22 PM
To: Mailvaganam, Hari; Lichten Stein;

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

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