See Earl’s response to the virtual attribute question. You shouldn’t be in the subject table once you have a real source. If you can get the uidNumber from
shib, that would work, or if eppn could be a subject identifier in your source, that would work, or we could add a patch to convert the eppn to a netId which would be a subject identifier…
Thanks,
Chris
From: Rob Gorrell [mailto:]
Sent: Friday, June 07, 2013 3:51 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-users] help configuring the Subject API for a JNDI source
I'm actually not using the quickstart...i started with the separate components and an empty database.
If I remove myself from the subject table, how is the UI going to authenticate me? or is that just a matter of making sure my shibb SP maps through a uidNumber into REMOTE_USER that matches a subject_id in my members table?
and another question... right now i have my sources.xml configured to map displayName through as the description. But what if i wanted description to be displayName + cn? is there a way to do this concatenation in sources.xml? i thought I saw a post saying
no, that it must be contained wholly in an LDAP attribute.
-Rob
On Fri, Jun 7, 2013 at 2:35 PM, Chris Hyzer <> wrote:
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.
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
--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
University of NC at Greensboro
336-334-5954
|
