Grouper Users - Open Discussion List

["William G. Thompson, Jr." <>]

Great question! And thanks to Carey for bringing up the deployment guide!

We are starting up work on the next version of the guide with an eye
towards filling in more details, and capturing a little more community
practice, so this thread is timely.

If we are following the guide, the first order of business is to
establish the natural language policy, and then let that drive the
reference groups. The actual organization and naming of folders and
groups is to some extent less important. Although as Carey points out,
the security model you'd like to achieve does have implications for
the folder organization.

Based on your initial post, it looks like one of the policies is:
"Application owners and testers have access to the QA environment, and
only employees are eligigble."

This calls out two application specific reference groups (app owners,
testers), one contraint based on an institutional reference group
(employees), and one access policy (access to the QA enviroment).

So following the guide, we'd start with the reference groups. One
might create something like this:

app:WebApp:ref:WebAppOwners - composite ref group for subject -> role mapping
app:WebApp:ref:WebAppTesters - composite ref group for subject -> role mapping

app:WebApp:ref:WebAppOwners_include
app:WebApp:ref:WebAppOwners_eligible

WebAppOwners_include is where you add other referece groups or
individual subjects (if just maintaing an ACL). You could also include
other ref groups that have been delegated out to various parties.

WebAppOwners_eligible is your constraint/filter group. This is where
you put the employees ref group to implement the eligibility
requirement.

WebAppOwners = WebAppOwners_include intersect WebAppOwers_eligible
("only employees are eligible")

Same thing for Testers.

Now we have our cohorts (i.e. reference groups) and can construct our
access policy groups.

app:WebApp:WebAppQA - composite access policy group

app:WebApp:WebAppQA_allow - allow group
app:WebApp:WebAppQA_deny - deny group

WebAppQA_allow includes WebAppOwners and WebAppTesters ("app owners
and testers have access")
WebAppQA_deny might include some global deny groups ("unless in some
global deny group")

WebAppQA = WebAppQA_allow - WebAppQA_deny

Making sense?

Best,
Bill

ps. other IGA systems might use the elibility group to prevent a
subject->role mapping in the first place rather than allow/leave those
assignments in the _include group. If you are just maintaining a
simple ACL you could use this the "Veto if not eligible" and the
"Composite_ng intersection" Grouper rules to acheive this, though it
will be a littler harder to "see" the policy directly in the Grouper
UI.
https://spaces.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Veto+if+not+eligible
https://spaces.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Composite-ng+intersection

On Fri, Dec 8, 2017 at 3:07 PM, Black, Carey M. 
<>
 wrote:
> REF: Grouper Deployment Guide Work -TIER Program
>
>
>
> https://spaces.internet2.edu/display/TI/TI.25.1?preview=%2F110336318%2F110336319%2FTI.25.1-TIERGrouperDeploymentGuide.pdf
>
>
>
> section 5.2.5 app:
>
>                 Not a lot of detail about what you should/”should not” do
> for the application Access Control Model. ( Because it likely greatly
> depends on the application and how it works with it’s ACLs.)
>
>
>
>                 I however think it is wise, when you are planning how to
> setup the data in grouper, to also consider the questions of:
>
>                                 Who will be controlling the ACL?
>
>                                 How will the ACL’s be used? ( Just by this
> one app? Shared among multiple apps? Etc…)
>
>                                 What does the infrastructure look like?
>
>                                                 Do you have completely
> parallel, independent infrastructure for dev, test, prod?
>
>                                                 Or do you really only have
> one: “Grouper”, “LDAP”,  “SOR’s”, “applications”?
>
>
>
>                 If you will only have one Grouper services ( used for Dev,
> Test, and Prod environments)  then a folder structure seems reasonable.
>
>                 If you will have three independent Grouper services ( used
> for Only one of Dev, Test, and Prod environments)  then a folder structure
> would not seem reasonable.
>
>
>
>                 Also consider if you are publishing the Grouper data to an
> LDAP, 2 LDAP (Dev, Prod), or 3 LDAP servers ( Dev, Test, Prod). [ Same for
> RDBMS publishing. ]
>
>                 Will the application be exposed to the full path or just
> some portion of it?
>
>                                 AKA :app:WebApp:Dev:Users    vs “Users”.
> “Dev:Users”, or “WebApp:Dev:Users”
>
>                                 Maybe the “Dev/Test/Prod” part should be
> above the app folder?
>
>                                                 AKA :app:Dev:WebApp:Users
> vs “WebApp:Users”, or “Dev:WebApp:Users”
>
>                                 Would it be possible for an environment (of
> the application) to honor the wrong environment data from Grouper?
>
>                                 Will the internal workings of the app always
> work the same way based on your choices as you move your code through the
> environments?
>
>
>
>                 Lots of things to consider that are hard to make a “general
> plan that would work for everyone”.
>
>
>
>
>
> In the deployment guide lingo….
>
>                 It looks like your {APP}Owners, {APP}Developers,
> {APP}Testers would be considered “application specific reference groups”( So
> they would be better in a sub folder by themselves …:ref ).
>
>                 The {APP}-DEV, {APP}-QA, {APP}-PROD would be the access
> control policies (ACP’s). (Which you may or may not want in separate folders
> at the same level as “:ref”. )
>
>                 You may also want to use the “…:etc” folder to help control
> the Grouper ACL’s to the Apps ACLs. J
>
>
>
> So maybe with “one grouper to rule them all”….
>
>
>
>                 :app:WebApp:etc
>
>                 :app:WebApp:ref
>
>                 :app:WebApp:DEV
>
>                 :app:WebApp:TEST
>
>                 :app:WebApp:PROD
>
> OR
>
>                 :app:DEV:WebApp:etc
>
>                 :app:DEV:WebApp:ref
>
>                 :app:TEST:WebApp:etc
>
>                 :app:TEST:WebApp:ref
>
>                 :app:PROD:WebApp:etc
>
>                 :app:PROD:WebApp:ref
>
>
>
> OR
>
>                 Use more than one Grouper and just have this on both
> instances
>
>                 :app:WebApp:etc
>
>                 :app:WebApp:ref
>
> OR…
>
>                 Well you get the idea. J
>
>
>
> Hope that helps.
>
>
>
> --
>
> Carey Matthew 
> 
>
>
>
> From: 
> 
> [mailto:]
>  On Behalf Of Peter DiCamillo
> Sent: Friday, December 8, 2017 1:20 PM
> To: Tomo O'BRIEN 
> <>;
>  
> 
> Subject: Re: [grouper-users] Web app environment-specific groups?
>
>
>
> When we've done that, we've used folders for the different environments. The
> APP folder would contain PROD, QA, and DEV folders (or whatever environments
> you require.) In each environment folder there would be individual role
> groups, such as Owners, Developers, and Testers as you mentioned. So one
> group might be APP:QA:Testers. I don't know that there's any Grouper best
> practice for this. I'd like to know about it if there is.
>
> Peter
>
> On 12/8/17 12:49 PM, Tomo O'BRIEN wrote:
>
> Hi folks,
>
>
>
> We're interested in environment-specific groups like {APP}-Dev, {APP}-QA,
> {APP}-UAT, {APP}-Prod so we can have appropriate permission groups for each
> environment.
>
>
>
> I haven't seen this pattern described on the wiki but maybe I'm just not
> looking in the right places?  Has anyone developed a naming/composite
> structure for this situation?
>
>
>
> I'm thinking about something like:
>
>
>
> {APP}Owners (functional owners)
>
> {APP}Developers
>
> {APP}Testers
>
>
>
> {APP}-DEV (union of Owners + Developers or maybe just Developers)
>
> {APP}-QA (union of Owners + Testers)
>
> {APP}-PROD (just Owners)
>
>
>
> At some point we'd also have an intersection with our Employees + include -
> exclude group -- not sure where this is best positioned - after the ad hoc
> owners/developers/tests group or after the union of owners+testers or
> developers
>
>
>
> Any thoughts or suggestions would be appreciated!
>
>
>
> Thanks!
>
>
>
> Tom O'Brien
>
>
>
>
>
>