subject id should allow for logic to transform the data when searching or returning data

From: Black, Carey M. black.123@osu.edu
Sent: Tuesday, April 04, 2017 6:57 PM
To: Hyzer, Chris <mchyzer@isc.upenn.edu>; grouper-users@internet2.edu
Subject: 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. 

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