Subject: Grouper Users - Open Discussion List
[grouper-users] Checking group name uniqueness across multiple sources
- From: Greg Haverkamp <>
- To: "" <>
- Subject: [grouper-users] Checking group name uniqueness across multiple sources
- Date: Mon, 26 Mar 2018 13:12:53 -0700
Warning: I’m largely a complete n00b.
After years of poking at Grouper, we’re pushing through with getting it ready to deal with some specific use cases, the most important of which is publishing Google Groups. We manage the @lbl.gov namespace entirely from our enterprise directory, and we use a simple RESTful API to make name availability accessible. e.g.:
will check for any existing email address (appends @lbl.gov), email alias, mail forward, Google Group, as well as a couple of other naming contexts. We don't permit any reuse among these sources. All of these names are stored in one attribute or another in the directory.
So, I'm trying to understand either the "right" way or a "best" (or even "better") way to do this, without a whole lot of experience with Grouper. I'm pretty much only armed with documentation, a few aborted instances, and a couple of years on the grouper-users list.
Essentially, I want to intercept group creation to check to see if a desired Google Group group name clashes with another name in our namespace. Off-hand, it appears to me that there are two options:
1. Write a hook that makes the RESTful call. This seems like the most straightforward solution, but it also seems a little daunting to a person just starting out with Grouper. Plus, I'm the only person on my team who writes Java, so we've eliminated it where possible. (We've still got a fair amount of Java, what with our custom Shibboleth modules and stuff, so this may be a non-issue.)
2. Bring in all of the data as subjects. People are already coming in, and we could include the alias attributes (lblAccountMailAlias and lblAccountUsernameAlias). Mail forwards (i.e., what most people would call "sendmail" aliases) and existing Google Groups live as distinct object classes in the directory, as well, though not as people. So, presumably they could all be brought in as subjects and could be deconflicted that way.
3(?) I don't know if Rules make sense over hooks, or if they're even a viable possibility.
#1 strikes me as the cleanest, because it keeps all of the logic where it is, is agnostic to location (e.g., if we ever move that information out of the directory into a database or an IdM system, we'd just have to update the location of the call.) #2 seems, with enough work, potentially doable entirely in Grouper as it stands, though I'm not sure if it actually is possible to check all of those additional attributes as well as subject names.
Any recommendations on the "best" way to approach this?
- [grouper-users] Checking group name uniqueness across multiple sources, Greg Haverkamp, 03/26/2018
- Re: [grouper-users] Checking group name uniqueness across multiple sources, Jeffrey Crawford, 03/27/2018
Archive powered by MHonArc 2.6.19.