Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

> You specifically annotate next to “netId” with "blank for external users”.  

 

I was thinking a subject attribute eppn (or subjectId in your case), would be or .

If you have internal apps that aren’t tied to other IdP’s, you could expose netId as “gettes” and there wouldn’t be external users there, but for subjects that are external, the netId attribute would be blank if they don’t have a florida netId.  Know what I mean?  Centrally its not an ideal pristine thing but for app developers it’s a welcome shortcut.  You can do this however you like if you disagree.

 

Does anyone use the JDBC1 subject adapter in a way that cant be converted like this?

 

https://spaces.internet2.edu/display/Grouper/Migrating+from+the+Grouper+JDBC+subject+source+to+the+JDBC2+subject+source

 

We harmonized the two ldap subject adapters into one (years ago) so we might as well do the same for subject adapters.  Perhaps we could do that when we make the wizard for subject adapters.

 

Thanks

Chris

 

From: Gettes, Michael [mailto:]
Sent: Thursday, May 17, 2018 7:49 AM
To: Hyzer, Chris <>
Cc: Mailing List <>
Subject: Re: [grouper-users] migrating from jdbc1 subject source to jdbc2 subject source

 

Hi Chris,

 

Firstly, a big thank you for your assistance the last couple of weeks helping to work these issues through and for supplying this write-up for the community to benefit from what we’ve learned.  This is working like a charm for us now as we hopefully progress with a Grouper deployment at UF.

 

Secondly, I have a question regarding the write-up.  You specifically annotate next to “netId” with "blank for external users”.   To me, an external user would have a different eduPersonPrincipalName form from the rest of the population and would be in a subject source and will be unique from all those in the other subject sources per Grouper rules of subject sources.  So, Could you please explain what you mean with that annotation so I might benefit from you and your team’s experiences?

 

As I noted to you privately, given the issues of the last couple of weeks I believe it is time to deprecate and remove the original Grouper source adapter since with this mechanism people should be able to, if not easily, migrate away from it fairly quickly.  I’m sure there are people out there doing weird things, there always are, but I think it would be good to do so especially as I feel so badly about the amount of time I helped to waste of you, Chris Hubing, and Paul Caskey.  I guess the good news is we found there are problems with the original adapter and an effective workaround.

 

Thank you - again - for all you do.  (And a huge thank you to Chris Hubing and Paul Caskey, and John Gasper, who are doing awesome work with the TIER Grouper packaging).

 

/mrg

On May 16, 2018, at 3:24 PM, Hyzer, Chris <> wrote:

 

If you use the JDBC1 subject source, do you have any issues with it?  If you are going to use a new SQL source, I recommend the JDBC2 source J

 

We have some issues at Florida, and here is a wiki on converting from JDBC1 to JDBC2, and it solved their issues (the pool in JDBC did not handle terminated oracle connections properly and didn’t log this either).  Note, this is a separate pool than if your subject source uses the same database connection as the Grouper registry itself.

 

https://spaces.internet2.edu/display/Grouper/Migrating+from+the+Grouper+JDBC+subject+source+to+the+JDBC2+subject+source

 

Thanks

Chris