Grouper Users - Open Discussion List

[Chris Hyzer <>]

>
> I had just copied the code from the samples cargo-cult-style, which
> worked for 1.3.0. Making a user "actAs" the same user is obviously a
> bit
> pointless, so maybe the error message in this case could just point out
> that "actAs" is not required.

OK, no problem, I added a jira issue and will go this for 1.4.1:

https://bugs.internet2.edu/jira/browse/GRP-202

Also, if you are using Java, and aren’t too far along, you might want to 
consider taking the grouperClient jar (and grouper-client.properties config 
file) as a web service client, and just using that API.  It is more high 
level and more likely not to break on upgrades to the server code:

e.g. to add a member to a group:

WsAddMemberResults wsAddMemberResults = new 
GcAddMember().assignGroupName("aStem:aGroup").addSubjectId("12345").execute();

>
> I am little unclear as to how I should specify the user for my web
> client. Currently the client just imports users and groups from my
> sources of records, and I have just configured
>
>         ws.testing.user
>         ws.testing.pass
>
> in
>         grouper-ws.properties
>
> to user GrouperSystem.
>
> What would be the preferred method for specifying the credentials for a
> functional administrative user?

Do you use Kerberos at your school?  At penn we take the user/pass and 
authenticate with Kerberos, which is built in to Grouper WS.  Alternatively, 
you can:

1. Use servlet container authentication.  E.g. for tomcat, add the user/pass 
to the tomcat-users.xml file, then it should work

2. Make a custom authentication class to hook into whatever authentication 
your school has (or if it is generic, let me know and I can add one).  E.g. 
is it a bind to a an LDAP or a lookup from ldap or something?

This stuff should be explained here, but let me know if you need more info or 
help:

https://wiki.internet2.edu/confluence/display/GrouperWG/Authentication+for+Grouper+Web+Services

Kind regards,
Chris