Grouper Users - Open Discussion List

[Chris Hyzer <>]

Subject table is just for testing and quick start…

 

Might want to remove yourself from that, and remove your member table entry from the subject table.  To do that, might want to try the gsh “member Change Subject” command.  Or wipe your registry and start over.  Further, once you are done with quick start, remove the local subject source altogether from the sources.xml and member table J

 

Thanks,

Chris

 

From: Rob Gorrell [mailto:]
Sent: Friday, June 07, 2013 2:21 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-users] help configuring the Subject API for a JNDI source

 

I'm getting there... just slowly! part of what is confusing me is the relationship between the subject table and the grouper_members table... it would seem the subject API is only adding to the members table, correct? users that can log into the system and interact with UI must be hand provisioned into the subject table and won't be added as a result of the subject API and being picked from the picker?

We appear to be similar to Penn, in that we have a uidNumber (84374) that is unique numeric number persistent across the lifetime of the account. We also have cn (rwgorrel) that our users are more used to interacting with, and is unique but not entirely persistent as we do allow for username renames. It would seem uidNumber is the correct choice for SubjectID and we want to be able to resolve cn as a SubjectIdentifier.

Whats still confusing is I've created myself as a subject in the internal grouper database using eppn () as my subjectid which gives me an entry into the members table. but as someone picks me using the ldap datasource, my subjectid is then uidNumber (84374) and then i'll have two rows in members... which seems suboptimal to rely on users to pick the appropriate data source when searching to add me as member. Instead, it seems like I should only have 1 row in members, but in order to do that, wouldn't it require changing my subjectid in the subject table from eppn to uidNumber? whereby then UI would have trouble logging me in via shibboleth and the eppn being passed to REMOTE_USER?

-Rob


If I'm both an interactive user and a member of groups, what keeps my objects from these two data sources tied together so when someone is searching, they addd

On Fri, Jun 7, 2013 at 1:40 PM, Chris Hyzer <> wrote:

SubjectID: should be unchanging (probably opaque).  At Penn we use PennID, e.g. 12345678.  There is one of these for a subject, and it would be nice if multiple sources did not have the same subjectId.

 

SubjectIdentifier: can be anything that resolves to a subject.  At Penn we use PennKey (netId), e.g. mchyzer, or eppn, e.g. .  This can be non-opaque, can change for a user, etc.  In one source, two identifiers cannot point to the same subject.  It would be nice if multiple sources did not have the same subjectIdentifier.

 

So… I would recommend eppn for external users’ subjectId, since that is likely the best thing you’ve got.  Note: external users could be a separate source than local users.  For local users’ source, I think uidNumber is not a bad choice, and eppn could be a subjectIdentifier that could lookup that user.

 

Ok?

 

Thanks,

Chris

 

From: Rob Gorrell [mailto:]
Sent: Friday, June 07, 2013 1:16 PM
To: Shilen Patel
Cc: Chris Hyzer;

Subject: Re: [grouper-users] help configuring the Subject API for a JNDI source

 

So let me ask a couple more questions along this vein...

The goal of the Subject API is to add subjects to the Subjects table from a data connector (such as JNDI), correct? The subjects I've added manually so far (through gsh) so I can use the system, i've used eppn as the subjectid since my UI install authentication is shibbolized. I'm assuming I would like subjects loaded by the Subject API to also use eppn as the subjectid. trouble is, our ldap directory doesn't store eppn as an attribute, our shibb IdP computes it by scoping the cn attribute. Can grouper do a similar thing in sources.xml when it comes to the subjectid attribute? I would rather load subjects as eppn, not uidNumber, as shibb won't be authenticating users to my grouper UI based on uidNumber but rather eppn.

-Rob

On Thu, Jun 6, 2013 at 3:40 PM, Shilen Patel <> wrote:

In your sources.xml file, is your filter perhaps not right for the "searchSubject" search type?  This is the search to find the user by subject id.  The logs below seem to suggest that your filter is this:  (& (uncgPreferredName=%TERM%) (objectclass=userProxy))

 

But you previously said your subject id attribute is uidNumber.

 

Thanks!

 

-- Shilen

 

From: Rob Gorrell <>
Date: Wednesday, June 5, 2013 2:14 PM
To: Chris Hyzer <>
Cc: "" <>

Subject: Re: [grouper-users] help configuring the Subject API for a JNDI source

 

So thank you for the education about logging... I think i have a grasp on where to look now.

what I get in the grouper_error.log when i try to bring up/show a subject's attributes is:
2013-06-05 14:09:37,738: [TP-Processor8] ERROR PopulateSubjectSummaryAction.grouperExecute(369) - < 50FB33F3960149BC379AA3ADC3E3AA5C-0008 10088e20ca0d4ad2af3cf7c71aea5d3c jdbc > - edu.internet2.middleware.subject.SubjectNotFoundException: No results: searchSubject filter:(& (uncgPreferredName=%TERM%) (objectclass=userProxy)) searchValue: 33668
2013-06-05 14:09:37,747: [TP-Processor8] ERROR PopulateSubjectSummaryAction.grouperExecute(436) - < 50FB33F3960149BC379AA3ADC3E3AA5C-0008 10088e20ca0d4ad2af3cf7c71aea5d3c jdbc > - edu.internet2.middleware.grouper.exception.MemberNotFoundException: Unresolvable subject is also not a Member

and when I try to assign privileges, I get:
2013-06-05 14:12:04,207: [TP-Processor2] ERROR DoAssignNewMembersAction.grouperExecute(246) - < 50FB33F3960149BC379AA3ADC3E3AA5C-0011 10088e20ca0d4ad2af3cf7c71aea5d3c jdbc > - edu.internet2.middleware.subject.SubjectNotFoundException: No results: searchSubject filter:(& (uncgPreferredName=%TERM%) (objectclass=userProxy)) searchValue: 33668
2013-06-05 14:12:04,211: [TP-Processor2] ERROR NavExceptionHelper.getMessage(107) - < 50FB33F3960149BC379AA3ADC3E3AA5C-0011 10088e20ca0d4ad2af3cf7c71aea5d3c jdbc > - Missing nav key: The entity does not exist.

which is odd considering i can match the subject in the LDAP source, but then it seems to fall apart from there.

-Rob

On Tue, Jun 4, 2013 at 5:16 PM, Chris Hyzer <> wrote:

Can you put an absolute path in the log4j.properties and restart and reproduce?  (or log to stdout)

 

You should see something like this in the catalina.out

 

“Grouper is logging to file:”

 

Thanks,

Chris

 

 

From: [mailto:] On Behalf Of Rob Gorrell

Sent: Tuesday, June 04, 2013 4:29 PM
To: Chris Hyzer
Cc:

Subject: Re: [grouper-users] help configuring the Subject API for a JNDI source

 

Guess i'm not sure where this would be logged exactly? By the UI? where does the UI output its logs? i'm not seeing anything in Tomcat's logging?

-Rob

On Tue, Jun 4, 2013 at 4:25 PM, Chris Hyzer <> wrote:

Are there stacks in the logs that describe the error?

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Rob Gorrell
Sent: Tuesday, June 04, 2013 4:12 PM
To:
Subject: [grouper-users] help configuring the Subject API for a JNDI source

 

So I'm attempting to configure the Subject API to pull in subjects from our LDAP directory. Using the example sources.xml, I was able to configure the LDAP section such that when in the UI, I'm able to search and locate a subject based on username (the description appears next to their check box), however, when I attempt to assign  privileges, I get an "error retrieving entity [33668]. the entity does not exist." and likewise, when i click on the description of the located subject to bring up their attributes, I get an "error: there was an unexpected error retrieving the requested entity as a member". I feel like I'm missing something in the attribute mappings preventing the user from being added, just not sure what that something is.

I have the following attributes defined like this in sources.xml...

     <init-param>
      <param-name>SubjectID_AttributeType</param-name>
      <param-value>uidNumber</param-value>
    </init-param>
     <init-param>
      <param-name>SubjectID_formatToLowerCase</param-name>
      <param-value>false</param-value>
    </init-param>
    <init-param>
      <param-name>Name_AttributeType</param-name>
      <param-value>cn</param-value>
    </init-param>
    <init-param>
      <param-name>Description_AttributeType</param-name>
      <param-value>displayName</param-value>
    </init-param>

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954