Grouper Users - Open Discussion List

[Chris Hyzer <>]

There is a group in grouper-ws.properties 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)
ws.client.user.group.name = 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...

https://spaces.internet2.edu/display/GrouperWG/Starting+with+Grouper

Thanks
Chris

-----Original Message-----
From: Mailvaganam, Hari 
[mailto:]
 
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):


1) 
grouper-ws_v1.3/build/dist/grouper-ws/WEB-INF/classes/grouper-ws.example.properties

2) grouper-ws_v1.3/resources/ grouper-ws.example.properties


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

Thanks.

Best regards,
 
Hari


-----Original Message-----
From: Chris Hyzer 
[mailto:]
 
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

Right

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 grouper-ws.properties

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

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.

Regards,
Chris