Grouper Users - Open Discussion List

["Jeremy Wickham" <>]

I figured I wasn't too clear in my email, I was having a hard time trying to explain.

 

We're not expecting the user to know the names or IDs of the groups in which they want route their document to, so we'll need a way for a user to lookup groups while inside Kuali. I see that you have the lookupGroups method in there but throw a runtime exception stating that it is not implemented. So I implemented that method for a lookup. I got off on a tangent trying to find a way to query groups and came across the JDBC2 adapter.

How do you currently allow your user to look up a group while inside of Kuali?

>>> Chris Hyzer <> 11/17/2011 1:01 PM >>>

Ok, if you have specific questions let me know…

JDBC2 adapter is the next generation, if you have a view of your data which is in one table, it is probably ideal.  Im not sure how the source adapter helps with kuali though, you want kuali groups to be available as subjects in grouper?

You need a lookup for groups in the kuali connector?  Im not sure what you mean by this, you need to describe in more detail.

 

Thanks,

Chris

 

 

 

 

From: Jeremy Wickham [mailto:]
Sent: Thursday, November 17, 2011 1:12 PM
To: ; Chris Hyzer
Subject: RE: [grouper-users] Kuali and Grouper Integration

 

Wow, it's been a while since I've check my listserv folder. I apologize about this.

 

Yes, I have made a lot of progress with this actually. I removed the sourceSeparator and everything started to fall into place. I also figured out that I needed the id of the subject in Grouper to be the principal id in Rice. I was trying to match the principal name to the ID in Grouper.

 

There are a couple pitfalls I have come across though:

 

I mapped our Employee group in Kuali to an Employee group in Grouper in the grouper.client.properties file. That "Kuali" group drove our Employee role. Then the lookup for the group was executed when trying to imitate an Employee document, it would use the Grouper uuid to query for the group inside of Kuali and would then fail every time because that Kuali group ID didn't exist. I have a work around for this, but how I did it has left me and I seem to have not write it down. Great, but it's working for right now.

I need a lookup for groups with the Kuali connector. I wrote a quick and dirty lookup, but it's not really my best work. I am still in the very early learning stages of Grouper and really trying to figure out the differences between the GrouperJdbcSourceAdapter and the GrouperJdbcSourceAdapter2, how one would benefit me versus the other. From what I've been reading is that the second adapter will let me do more complex searches. Would this help in writing a lookup?

 

I am also not overriding the PersonService with Grouper. We are storing more information in KIM than I initially realized.

 

Thank you for the follow up on this. I am still learning and discovering a lot of things, when it can be my main focus.

 

If you don't mind I would like to keep some dialog open about this. I'm still not 100% sure that we will use Grouper within Kuali, but I am almost certain we will use Grouper at our university in the future.

 

Cheers!

 -Jeremy

>>> Chris Hyzer <> 11/7/2011 9:44 PM >>>

Were you able to make progress on this?

 

From: Jeremy Wickham [mailto:]
Sent: Tuesday, November 01, 2011 3:44 PM
To: ; Chris Hyzer
Subject: RE: [grouper-users] Kuali and Grouper Integration

 

We are using the latest Kuali Rice release, 1.0.3.3. If I were to comment out the overrides in grouperKimOverride.xml I am able to initiate the documents.

 

Now that you say the Kuali API more than likely changed, I have a starting point to look.

 

Let's see if I can uncover most of my findings. When Grouper returns back after login, the actualPerson object in the Kuali UserSession has:

entityId = jdbc::::jrw16

entityTypeCode = PERSON

principalId = jdbc::::jrw16

principalName = jrw16

 

I know these conflict with what we had initially loaded into KIM. Our entityId and principalId were the same, but they were our unique identifier coming from our main enterprise system. Does this conflict with the roles and permissions?

>>> Chris Hyzer <> 11/1/2011 1:51 PM >>>

Which version of Kuali are you using?  Any chance you can use 1.0.2.1?  J  The connector is flexible with what version of Grouper you use, but the Kuali API seems to change LOT from release to release (even point releases).

I think your config looks ok…   I assume your permissions and roles are in Rice right?

 

Here is my config:

 

##############################

## Kuali Group Settings

##############################

 

grouper.kim.kimGroupIdToGrouperName_1 = someFolder:kualiRice:etc:kualiAdmins

 

 

##############################

## Kuali Identity settings

##############################

 

kuali.identity.source.id.0 = pennperson

kuali.identity.source.nameAttribute.0 = description

kuali.identity.source.identifierAttribute.0 = PENNNAME

kuali.identity.source.emailAttribute.0 = EMAIL

kuali.identity.source.entityTypeCode.0 = PERSON

 

# separate a sourceId from a subjectId or sourceId

kuali.identity.sourceSeparator = ::::

 

# Stem where KIM groups are.  The KIM namespace is underneath, then the

# group.  Wont break anything, but better to not have trailing colon

kim.stem = someFolder:kualiRice

 

# if there is this subjectId from grouper, dont untranslate to put sourceId::::subjectId

# multiple, comma separated

kuali.identity.ignoreSourceAppend.subjectIds = admin

 

###############################

# group requird on login (if using the grouper kuali authenticator

kuali.authn.require.group = someFolder:activeNonAlumniWithPennname

 

 

 

 

From: [mailto:] On Behalf Of Jeremy Wickham
Sent: Tuesday, November 01, 2011 2:39 PM
To:
Subject: [grouper-users] Kuali and Grouper Integration

 

I have installed the Grouper Connector into Kuali. I am able to log into Kuali, but I do not seem to have any authorization documents. It is somehow not following my permissions and roles that I have defined.

 

When we first installed Kuali we decided that the entity id and principal id were to be the same and will be our unique identifier, and the principal name was going to be the username.

 

I have been put on the fast track to see if I can get this working pretty quickly so I am positive that I am overlooking something simple. I also have kept a lot of the default values. Below I have added the grouper.client.properties that I have changed the the grouper-ws.properties.

 

grouper.client.properties (Which resides in Kuali)

########################################
## Grouper Kim Connector
########################################

 

grouper.kim.plugin.subjectSourceId = jdbc

grouper.kim.plugin.subjectSourceIds =

kim.stem = msstate:apps:kuali:kim

grouper.types.of.kim.groups =

##############################
## Kuali Identity settings

 

kuali.identity.source.0 = jdbc
kuali.identity.nameAttribute.0 = name
kuali.identity.identifierAttribute.0 = loginid
kuali.identity.source.emailAttribute.0 = EMAIL
kuali.identity.source.entityTypeCode.0 = PERSON

 

# separate a sourceId from a subjectId or sourceId
kuali.identity.sourceSeparator = ::::

 

grouper-ws.properties

ws.subject.result.detail.attribute.names = name, description, loginId, EMAIL

 

Thank you for your help!

Cheers!

 

 

 

 

Jeremy Wickham
Senior Programmer Analyst
Enterprise Information Systems

(662) 325-9173