Grouper Users - Open Discussion List

[Shilen Patel <>]

Carey,

Just curious, what is the name of this attribute?  Is it part of some standard object class or custom developed?

Thanks!

- Shilen

From: <Redman>, Chad Eric <>
Date: Wednesday, April 5, 2017 at 3:37 PM
To: "Black, Carey M." <>, "Hyzer, Chris" <>, "" <>
Subject: [grouper-users] RE: GrouperJndiSourceAdapter questions...

I realized later that your IDs may be binary and not necessarily unicode. This would be less likely to work without customization.

 

So maybe moot, but if anyone is interested, the issue with various pages not working with a unicode subject ID has to do with URI parsing not defaulting to unicode. The fixes are (a) set the Tomcat URI decoding (http://stackoverflow.com/a/16530462); or (b) decode specific parameters as needed in the Java classes that use them.

 

-Chad

 

 

From: [] On Behalf Of Redman, Chad Eric
Sent: Wednesday, April 05, 2017 1:59 PM
To: Black, Carey M. <>; Hyzer, Chris <>;
Subject: [grouper-users] RE: GrouperJndiSourceAdapter questions...

 

Carey,

 

I had thought that LDAP had built-in base64 translation which was transparent at the application level, so I did some testing on a demo database. I created an LDAP entry with an accent in the uid field (the subject ID in this demo db). Indeed, an LDAP search will display a base64 string as the value for the field. However, you can't search for that base64 value, only the original value with escaped unicode (e.g., uid=jlop\c3\a9z).  The Grouper UI was able to search on the unicode string (but only certain search forms work), display it correctly, and add that subject to a group. The subject is stored in the database correctly as the unicode string. What doesn't work is displaying the subject detail page. The error is "Cannot find subject". I network traced the LDAP call and that's fine. I turned on SQL debugging, and Grouper is able to query the subject in its subject table and get the attributes, as if it's about to display the subject page. So somewhere between there and the page generation there is some issue.

 

Anyway, I was just curious if binary subject IDs would work with no additional work, and the answer is, almost.

 

-Chad

 

 

 

From: [] On Behalf Of Black, Carey M.
Sent: Tuesday, April 04, 2017 6:57 PM
To: Hyzer, Chris <>;
Subject: [grouper-users] RE: GrouperJndiSourceAdapter questions...

 

Chris,

 

>> Does this adapter support using Base64 encoded attributes as the SubjectID attribute?

> 

> I don’t think that is currently possible, if you need it please open a descriptive jira about it.  I assume that when searching the ID will need to be encoded before running the filter?

 

It is actually more “odd” than that… but yes, the value needs decoded  (from Base64) before it is stored then “encoded” before the search can work.

                If you take the value in HEX then escape all of the digits then the ldap filter works.

 

                Example: (HEX form of the value)  4e99cb365b5dfc4998b74e99cb365b5d

                                  (valid filter )   (attribute=\4e\99\cb\36\5b\5d\fc\49\98\b7\4e\99\cb\36\5b\5d)

 

 

My motivation is to use a “system generated” value that I have never seen the LDAP system allow to have a duplicate. All other values are “mostly unique”, but I suspect that the system generated attribute that is stored in this “odd way” is system protected from being “non-unique” and is a very opaque value too. J

 

The only issue is that grouper does not appear read to deal with this type of data from an LDAP source. L

 

 

 

 

 

RE: setting email value

 

I already have this in my config. (But it is not working) Any other ideas of what I might be doing wrong?

“

<init-param>

       <param-name>emailAttributeName</param-name>

       <param-value>mail</param-value>

</init-param>

“

 

The LDAP source has a value for the attribute “mail” that is an email address. (example: )

 

When I use the Subject API diagnostics page I see this in the output for my Subject ID:

“

Subject attribute 'mail' has 1 value: '

  - with subject.getAttributeValue("mail")

“

 

REF: https://github.com/Internet2/grouper/blob/master/subject/conf/ldap.sources.xml.example

 

I do not see a sample for “emailAttributeName” and the format looks more like “Name_AttributeType”…..

 

REF: https://github.com/Internet2/grouper/blob/GROUPER_2_3_0-branch/subject/tests/edu/internet2/middleware/subject/provider/JNDISourceAdapterTest.java

                Only test for “SubjectID_AttributeType”, “Name_AttributeType” and “Description_AttributeTyp”.

                No email attribute looking value.

 

Is this just a “miss” in this API? (Or am I not seeing something?)

 

--

Carey Matthew

 

From: Hyzer, Chris []
Sent: Tuesday, April 4, 2017 3:17 PM
To: Black, Carey M. <>;
Subject: RE: GrouperJndiSourceAdapter questions...

 

> Does this adapter support using Base64 encoded attributes as the SubjectID attribute?

 

I don’t think that is currently possible, if you need it please open a descriptive jira about it.  I assume that when searching the ID will need to be encoded before running the filter?

 

> How do I map an attribute from this SourceAdaptor to the email value for the subject?

 

Just make an attribute, e.g. “emailAddress”, and then set this:

 

     <!-- If using emails and need email addresses in sources, set which attribute has the email address in this source -->

     <init-param>

       <param-name>emailAttributeName</param-name>

       <param-value>emailAddress</param-value>

     </init-param>

 

Thanks

Chris

 

From: [] On Behalf Of Black, Carey M.
Sent: Tuesday, April 04, 2017 2:26 AM
To:
Subject: [grouper-users] GrouperJndiSourceAdapter questions...

 

Hello,

 

First a bit about how I am currently configuring this subject API. ( in case it matters.)

  I am altering the sources.xml file.

 

 

Does this adapter support using Base64 encoded attributes as the SubjectID attribute?

                I am trying to tie to our IDM system and would like to use an operational attribute that is base64 encoded as the Subject ID for this data set.

                However, the system does not appear to “automatically know” that it needs to decode the value being returned from our ldap server.

                Is there a way to “give it a clue” so that it will do that for the attribute?

                If in include the attribute in the list of “attribute” to display when doing a search I see

 

How do I map an attribute from this SourceAdaptor to the email value for the subject? (or is intended to be dealt with some other way than the subject API?

                I was expecting something like, but I am not finding it in any of the docs.

“

<init-param>

       <param-name>Mail_AttributeType</param-name>

       <param-value>mail</param-value>

     </init-param>

“

 

--

Carey Matthew