Child pages
  • 20-Nov-2019 Grouper Deployment Guide Community Call
Skip to end of metadata
Go to start of metadata


Grouper Deployment Guide Community Call 

 Wed Nov. 20, 2019


  • Bill Thompson, Lafayette College
  • Chris Hyzer, Penn
  • Shilen Patel, Duke
  • Gerald Salvador, Fordham
  • Joli Patino, Fordham
  • Jason Peak, Oregon State
  • Andy Morgan, Oregon State
  • Erica Lomax, Oregon State
  • Erin Murtha, Internet2
  • Nick Roy, Internet2
  • Erik Coleman, Illinois
  • Emily Eisbruch, Internet2


Grouper Deployment Guide (Version 2, in the wiki)

Notes from Oct 23 call:


  • At the Oct 23, 2019 GDG call, there was discussion on updates and on some suggested new content
  • Today’s call is to finish off reviewing the feedback we’ve received.
  • Had hoped to have GDG v2 for Tech Ex (Dec 2019), but likely GDG v2 will be ready after Tech Ex → Latest expected delivery of GDG was TechEx → what is the commitment now? (erin)
  • Will craft a plan to do additional work on GDG , especially for new content, in 2020. 

Updated Content for GDG - part 2

  • Guidance on when to use the test: folder - Chris Hyzer
  • 3 options for test environments: 
    • 1. environment for testing Grouper,  
    • 2. High level folder and delegate orgs from there, 
    • 3 testing in an org folder
  • Add  best practices for Various test environments, to test the software or to test applications, 
  • At Penn, there was a test environment used for password changer
  • At  Lafayette, test environment is used for analysis,  production style string tests, be sure it’s working end to end , things not yet for production

  • Lafayette has separate testing Grouper, test QA Grouper, could also be used in other ways, it would be  good to have examples from the community of current practices
    • Test type attribute you can put on a folder
    • Important tip: Don’t use non production environment for something that will need to be up during the institution’s grouper maintenance or upgrade testing

  • ACM (access control model) model references - missing PIP, no ABAC discussion - Michael Gettes
    1. Call out to models 
    2. Balance between including ref material and linking to it
    3. Do better job of discussion how Grouper relates to standard access  control models
    4. Ad hoc groups inside of Grouper, for example

  • On-demand querying of membership via WS a provisioning category? - Chad Redman
    1. Getting data in and out of the system via on demand querying of membership via WS
    2. We mention loader jobs and PSPNG, but should cover more bases
    3. Need to add more guidance and info to the provisioning section of GDG
    4. Bill: we need to prioritize how much we can document in the GDG
    5. NickR: add a scoping section at front of GDG, what we are covering and what we are not covering, ask for volunteers potentially to document areas you are particularly interested in

  • Operational Considerations needs attention:   - Shilen Patel
    1. Looking for word Success on diagnostics page , needs clarification
      1. Even with an error, could still have word Success

Wiki Format

  1. In general, as we all probably know, things that were OK in the PDF format need to be lightened up a bit for the wiki, by using more boxes, more headings, shorter sentences, more bullets… - Emily Eisbruch
  2. GDG will be more dynamic, more findable on the wiki
  3. Previous/Next links on the left or the right - Chris Hyzer
    1. Screen reader considerations
    2. Did example here:

Additional Discussion

  1. AWS Roles and ACM3 - Chris Hubing
    1. I put a user in Grouper groups so they can get into a couple different AWS accounts, the IDP takes those memberships and sends attributes to the AWS SP (those attributes are called “AWSRoles”)
    3. Fodder for further work, 
    4. More examples, Make it more concrete
  2. Bundle vs ref and privilege management - Carey Black
    1. I can also see an approach that would just collapse this into the general ":ref" folder too. I think the only real advantage to having it separated is a separate space for grouper ACL's to let others ( outside of the grouper service team ) publish/maintain the "computed parts" based on the :ref  which I expect would be mostly or completely (maintained by the grouper service team )
    2. Grouper Dev team has already dropped Bundle vs ref, but need to clean up GDG
  3. Reference groups vs security groups (grouper privilege policy) - Julio Polo
    1. definition of reference group is too broad.  Almost anything that needs to be used in a policy group becomes a reference group.  Any group anywhere in Grouper that is used by a policy group is essentially a reference group. If you don't have a ref group for your departments application's exceptions (e.g. include the administrators), then do you use the existing org:compsci:etc:compsci_admin or do you create a new org:compsci:app:ref:admins that encloses the prior.  This example also illustrates the need to simplify the relationship between the ref, app and org folders.
    2. Reference Group is too broad
    3. Perhaps to add and define  “ad hoc”
    4. See if we want to include more in reference group bucket
    5. Or create an “Internal” group category or “helper” group
    6. Define and clarify 
  4. Consolidate app: and org: folders - Julio Polo
    1. I think we should consolidate app and org.  It gets confusing when you have to decide whether to create a group under app or under org.  The confusion gets worse when you have to think about whether a reference group is under ref or as a subfolder under either app or org.   We reserve the top-level ref for institutional reference groups curated by the IAM team. We only have an org folder. All enterprise apps just go under the organization that owns it.  Any policy group can make use of any org group as a reference group long as it has been granted access to do so. We don't force creating ref subfolders for org groups just because they're being referenced by a policy group.
    2. BillT: If all enterprise apps are under the org group, this is not prohibited under the model
    3. Chris: good to give options when explaining this
    4. Penn set up its structure prior to the GDG recommendations

  • GDG content and versioning
    • “Note that any software documentation for developers and end users that is related to a specific release of the software, and is distributed with software, is vetted as part of the quality assurance process for the software release and is out of scope for Trust and Identity Document Stewardship. “ 
    • ChrisH: the strategies  for content and versioning  on the wiki are to 
      • create a new wiki version of wiki doc per release  (not the Grouper project strategy)
      • have ONE Grouper WIKI and as we add features, document when a feature is in Grouper version x.x and above. 
    • Suggest we handle the GDG in same way as we handle the other Grouper wiki documentation 
    • Add notes about things that are not in older versions
    • Would expect people to look at the newest version of the GDG on the wiki
    •  Comment: Using Confluence tags might be helpful
    • Comment: would like inline notes to indicate when info in the GDG only applies to a certain version of Grouper
    • BillT: GDG does not want to be Grouper release specific;
      •  it’s about overall approach to access governance
      • We want the GDG to be more or less stable even with new features if possible
    • Chris: If there’s  a new general strategy in a newer Grouper version, then mentioning that strategy in the GDG can be a motivator for users to upgrade
    • Chad: Shib project does a good job,
    • Major branches in IDP v2 and V3, they have notes throughout the docs, sometimes superscripts, for any feature, it’s easy to see what version is needed. See example:
    • Update front matter with note about this and links to old doc.
    • Only maintain one publishing and one in-progress/editing version (can we do this in wiki?
    • Removed from Trust and Identity Document Stewardship
    • Maintain curated content vs open wiki content
    • Balance between standalone doc vs wiki content
    • Major revision/refresh/review with major Grouper release (next one would be 2.5)
    • Minor revisions directly to released version as needed
    • New content added as available, for a more dynamic doc

 Access models

  • There are 4 access control models in the GDG
  • Based on a year of discussions in the community
  • Distilling current community practice


ACM1 Grouper Subject Attributes

Eduperson affiliation / traditional shib SP IDP attribute release model

    • This is not the “GO TO” model
    • We want to stress policies instead of this approach
    • Policy admin is pushed to the SP in this model
    • Administering policy per service on grouper side is preferred 
    • Using Grouper to master a subject attribute , eduperson affiliation and using shib and SAML to communicate that to the target service, then target service handles access control
    • Chris: there was question about this at last training.  
    • Some software as a service wants an affiliation
    • But don’t want a policy group shared across  affiliation
    • This approach could address  that
    • Need to explain better how to use this model
    • Only do this if you have to
    • Don’t have different definitions per ref group per service

  • Advice should be to:
    • Try to keep ref groups stable
    • Build policy from those stable ref groups
  • If loose coupling and SP is happy with whatever definition for subject attribute, then it’s easy to deploy 

  •   tickets use case at Lafayette
    • Loose affiliation w software as a service used for tickets
    • If student , then they get the discount
    • Easy to implement
    • Would prefer access control model 2 if were reimplementing this now


ACM2 Grouper as PAP and PDP

  • This is the golden model, gets most value
  • Policy per service
  • Leverages power of Grouper in terms of delegated admin 
  • Can use point in time to see who had access
  • Helps keep ref groups stable


ACM3 RBAC User to Role Mapping

  • Cases where target service has some sophisticated management interface
  • Lafayette case: business intelligence system Cognos
  • Long list of permissions that can be mapped to a role
  • Can manually associate a user to role in Cognos
  • But better to use Grouper
  • So  split policy admin between target service (Cognos) and Grouper
  • So ACM3 is an extension of ACM2
  • If off the shelf app has 3 roles built in, you may want to use ACM 2. 
  • But ACM3 may be better if you can configure what the roles can do in the application,  Confluence is an example 
  • Policy is split in ACM3 


ACM4 WebSSO Short-circuit

  • Leverage Shib IDP to enforce access control. If you don’t have control over the target, here is another way you can do it
  • ChrisH: Please mention that the “coarse grained” can be a much wider net than the app needs.  I.e. if its only 200 people and the coarse grained is “employee” with 10k people, that might be ok
  • Please mention the PEP can be the IdP, or a load balancer (can do it with F5), or with a reverse proxy like apache, or with SP, or with application
  • If target service does not have a good user experience
  • If it will blow up in your face in some cases
  • Could implement with reference groups, etc. but implementation is slightly different


Comments on the ACMs

    • Note that ACM2, ACM3 and ACM4 are similar. 
    • ACM2 and ACM3 are quite similar
    • ChrisH suggests that we merge ACM2 and ACM3
    • With ACM3 there are 2 parts of the policy, who is in the role and what the role can do
    • Suggestion for ACM5, you can do RBAC inside of Grouper,  mainly used for Custom applications. 
    • ACM 6, is important, some apps are not conducive to externalizing , you can take those apps, get a feed or roles and permissions , load into Grouper and you can get reports, can get emails for manually unassign, 
    • State that you can do multiple access control approaches, depending on the target, you can mix and match 
    • BillT: yes could add ACM 5 and ACM 6

  • AndyM: Should the order we introduce the access models be considered? Maybe leading with the "gold standard" or leading with the least-capable model.  Could be ACM2, ACM3, ACM1, ACM4 (gold standard first) or ACM4, ACM1, ACM2, ACM3


  •  looking at the ACM wiki page, it’s confusing on what the models are all about
  • Need to rewrite to make sense 
  • Q: Are there uses at Duke that are not covered by one of the ACM models we have presented?
  • A: No, not off hand

Suggestions for ACM section of GDG: 

  • Need a table at top of the ACM page to summarize
  • P*P can get confusing, need a better definition for each one
  • More front matter to describe/clarify  and explain when each should be used
  • Get rid of the numbers for ACM1, ACM2, ACM3, ACM4, 
  •  Instead of numbers,   use descriptive titles
  • Create an opening paragraph to explain  
  • Current Number 1 and proposed number 5  (RBAC inside of Grouper,  mainly used for Custom applications) are least important
  • Need to add a meta description
  • Are there Other models?  


Summary: Lots of actionable items in the above suggested  improvements to the GDG and from the Oct 23 call.

Two buckets of improvements to the GDG:

  • Near term for initial “release”
  • Longer term ideas, capture them and figure out priority

Next steps and timeframe for GDG

  • At Tech Ex in Dec 2019, ACAMP breakout on Grouper Deployment Guide for discussion on updates made so far and get input on priority for longer term improvements

Getting the GDG work done 

  •   crowd source the work that needs to be done to the GDG
  • Bill has limited hours for this
  • It will be helpful to create tickets in JIRA for chunks of work to the GDG for tracking
  • Use the JIRA documentation bucket? Or create a GDG bucket? Perhaps a GDG 2 and GDG v3 
  • Erin: estimate of amount of time to make the improvements to the GDG?
  • Erin would like Some idea of when GDG v2 will be ready
  • Emily estimates: 4 hours to get the input into JIRAs, 
  • then perhaps 15-20 hours to get to “release-able” version of GDG
  • Let’s spread those 15-20 hours of work around to the “crowd” as much as possible!
  • Make Table with who it is assigned to… 
  • AI Chris will make a GDG category in JIRA with version tags
  • AI Bill will make the JIRAs 
  • Then those who have time can work on the JIRAs


 Notes in Zoom chat during GDG call :

  • From Andrew Morgan to Everyone: (12:10 PM)
I'd rather have some in-line notes when a particular GDG discussion only applies to a specific version of Grouper.  How many GDG things really require a specific version of Grouper?
There could also be a note at the top of the GDG, "Some parts of this GDG require version Grouper v2.4+"
or just a minimum version comment

  • From Andrew Morgan to Everyone: (12:11 PM)
I'm thinking of the group types, etc
if it gets out of hand in the future, the strategy could be revisited
(no microphone here)

  • From Chad Redman to Everyone: (12:17 PM)
(shib release notes as example of version clarity)
  • From Chad Redman to Everyone: (12:19 PM)
... and subpages are well marked as to version, e.g.
  • From Andrew Morgan to Everyone: (12:20 PM)

  • From Me to Everyone: (12:22 PM)
  • From Andrew Morgan to Everyone: (12:28 PM)
If an SP can only look at the eduPersonAffiliation attribute, you can still fake an SP-specific copy of that in Shibboleth, but it is fundamentally still a policy group that is SP specific.

  • From Andrew Morgan to Everyone: (12:38 PM)
Should the order we introduce the access models be considered?  Maybe leading with the "gold standard" or leading with the least-capable model
Could be ACM2, ACM3, ACM1, ACM4 (gold standard first) or ACM4, ACM1, ACM2, ACM3

  • From Andrew Morgan to Everyone: (12:50 PM)
I like the idea of eliminating the model numbers, and I support adding short descriptions of P*P at the top.
The graphics are great.  Why is there a smiley face next to the auth arrow?

  • From Andrew Morgan to Everyone: (12:54 PM)
OSU is interested in helping, but we're not sure on which areas.  Jira issues - awesome!


  • No labels