Grouper Users - Open Discussion List

[Nathan Kopp <>]

Ok… I’ve gotten this working.  Thanks for pointing me in the right direction!

 

However, this exercise has left me somewhat wanting regarding documentation of the Grouper API.  Here are a few example areas where I needed to look at the Grouper source code to determine the “right way” to use the API, and even then I feel like I’m guessing, since some things seem a bit tricky:

 

GrouperContext vs. Starting a GrouperSession with a Subject

When I start a session based on a subject (calling the static “start()” method), I would naturally expect that subject’s information to get written as the “loggedInMember” in the audit logs.  This doesn’t happen.  Instead, I have to create  a default GrouperContext and set it up with the Subject’s member UUID.

 

Which session is being used, and why?

For some actions, the root session is used.  Some methods use a non-root threadlocal session is used.  Some methods require a GrouperSession parameter.  I haven’t really discovered a consistent pattern that would help me to understand the proper ways to use sessions.

Compare: SubjectFinder.findByIdOrIdentifier(), MemberFinder.findBySubject(), UserAuditQuery.execute(), and Group.addMember()parameter

 

BWT, should I be asking these kinds of questions in the grouper-dev group instead of here?

 

-Nathan

 

From: [mailto:] On Behalf Of Nathan Kopp
Sent: Thursday, May 05, 2011 6:24 PM
To:
Subject: [grouper-users] RE: Attestation question

 

One thing that would be helpful also would be a list of things like:

* All possible audit type categories and audit type actions

* The fields(labels and their meanings) for the various audit types

 

The document you linked to seems possibly outdated.  For example, after some looking I discovered that I needed to use the action “addGroupMembership” (as opposed to either “addMembership”, “membershipAdd”, or “add_membership”).  Maybe this information can be queried easily using GSH.  If so, what commands would I use to gather this information?  After I do gather this information (if it’s not yet documented somewhere), I can volunteer to update the document with a table of the current valid values if you’d like.

 

-Nathan

 

From: [mailto:] On Behalf Of Nathan Kopp
Sent: Thursday, May 05, 2011 5:45 PM
To:
Subject: [grouper-users] RE: Attestation question

 

Chris,

 

Yes, that sounds like exactly what I’m looking for.  If you could send a Java API code snippet my way, that would be VERY helpful!  Thanks!

 

-Nathan

 

From: Chris Hyzer [mailto:]
Sent: Thursday, May 05, 2011 3:19 PM
To: Nathan Kopp;
Subject: RE: Attestation question

 

This is mentioned here:

 

https://spaces.internet2.edu/display/Grouper/User+auditing

 

This is GSH or just java…

 

you would do a userauditquery, set the group, set the user, set the type (e.g. membershipAdd), call execute(), get the audit entries that are returned, and get the most recent one, right?

 

If you need a code snippet let me know J

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Nathan Kopp
Sent: Thursday, May 05, 2011 3:14 PM
To:
Subject: [grouper-users] RE: Attestation question

 

No, the rules engine is the “responsible party” .  No need for “actAs”.

 

We will be using the Java API.  Using SQL would be “less than ideal.”  I was just wondering what classes/methods in the API that I could use to access the audit records.

 

-Nathan

 

From: Chris Hyzer [mailto:]
Sent: Thursday, May 05, 2011 2:52 PM
To: Nathan Kopp;
Subject: RE: Attestation question

 

So are you saying that the rules engine is the subject that is doing the add/remove, and you want to store who the end-user is that caused the rules engine to do the action?  If so then you could use “actAs” so the rules engine acts as the underlying user to do the action, then use the audit records.  To access the audit records, there is not yet a web service, but you could get the records with SQL or GSH, or the Java API…  Maybe you could more explicitly give an example so I can better explain Grouper’s capabilities.

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Nathan Kopp
Sent: Wednesday, May 04, 2011 10:31 AM
To:
Subject: [grouper-users] Attestation question

 

In my organization, we are beginning work on a Grouper implementation for managing user access to Siebel CRM.

 

One key thing we need to track is attestation (who is responsible for assigning a direct group membership) whenever our rules engine is responsible for membership.  We have identified two possible options:

1) use grouper’s audit log

2) store attestation information in an attribute whenever the rules engine is responsible for direct membership assignment

 

Currently we implemented this using an attribute.  However, I was wondering if there is an easy API for accessing the audit log to quickly the subject that is most recently responsible for a current group membership.  Does such a capability exist in the Grouper API?

 

Nathan Kopp

Applications Strategist

Information Technology Group

Campus Crusade for Christ, Int’l

407-826-2939 Office | 407-484-8485 Mobile | 407-826-2968 Fax