Skip to Content.
Sympa Menu

grouper-users - [grouper-users] RE: Attestation question

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] RE: Attestation question


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Nathan Kopp <>, "" <>
  • Subject: [grouper-users] RE: Attestation question
  • Date: Fri, 6 May 2011 13:34:25 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

 

> Ok

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

>

 

Great, congrats, I will assume you dont need code from me per previous email... :)

 

>

> 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.

 

Yeah, those are separate... there is no logged in user for gsh, because no one logged in...

it is only for ui/ws...  the grouperSession is used when actAs is used, so they are separate.

But yes, if you want to populate the loggedInMember, then you need the GrouperContext, good find!

 

>

> Which session is being used, and why?

 

The security of the registry is from GrouperSession, and GrouperContext is only used for auditing...

 

> 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.

 

Yes, this is complicated... for instance, lets say you have a subject A, and you are adding

a member B to group C.  The grouperSession is A.  Then the API needs to see if A is allowed

to UPDATE C.  But you need ADMIN to see if you can UPDATE something (look at privs), so it

does this call as GrouperSystem.  Then if it is ok, it will do the addMember as A.  See?

 

Anyways, as a rule you should start a GrouperSession as who you want to act as, either a

regular subject or GrouperSystem.

 

Another complication is things are only well defined for the UI, WS, and client.  The API

is a free-for-all, which is why you are confused...

 

>

> Compare: SubjectFinder.findByIdOrIdentifier(), MemberFinder.findBySubject(),

> UserAuditQuery.execute(), and Group.addMember()parameter

>

 

Right, you are saying some of these honor the GrouperSession, and some dont?  Im not surprised,

the Grouper developers need to look at code to figure it out too... :)

 

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

 

Probably better on dev, but doesnt really matter

 

Thanks,

Chris




Archive powered by MHonArc 2.6.16.

Top of Page