Child pages
  • Grouper Call 27-Apr-2011
Skip to end of metadata
Go to start of metadata

Draft Minutes: Grouper Call  27-April-2011


Tom Barton, University of Chicago (chair)
Chris Hyzer, University of Pennsylvania
Shilen Patel, Duke  
Jim Fox, University of Washington
Gary Brown, Bristol
Tom Zeller, U. Memphis
Steve Olshansky, Internet2  
Emily Eisbruch, Internet2 (scribe)  

*** For Grouper 2.0 Release: Code freeze on Monday, May 16 ****

New Action Items

[AI] (TomZ) will create a wiki page on steps to address real time provisioning.

[AI] (Jim) will create a wiki page showing a script for converting data from an existing approach when deploying Grouper

[AI] (Everyone) look at the Grouper 2.0 highlights wiki page and verify that the information is correct.

Carry Over Action Items
[AI] (Chris) will implement member search and sort in the Lite UI

[AI] (Shilen) will implement member search and sort in the Grouper Admin UI

[AI] (Chris) will put attribute framework UI work on demo site

[AI] (Rob) will follow up with Danno on obtaining the server for the Continuous Integration Environment.

[AI] (TomZ and Chris) will discuss/work on LDAP Grouper Loader for importing groups. JIRA 442

[AI] (Everyone) review Rob's chapters and give him feedback on the Grouper Users List.

[AI] (TomB) will explore new international participation for work on the Grouper UI (status: will handle this on release of Grouper 2.0)

Reminder:   Agendize Grouper UI strategy


Real-Time Provisioning

    • Lynn Garrison from Penn State presented at the Grouper WG at 2011 SMM with focus on the gap between what Penn State needs and what Grouper currently provides in the area of real-time provisioning.
    • TomZ has been thinking about the best approach to close that gap.
    • Using the Shib Attribute Resolver to represent changes (to group membership, for example) is very difficult
    • An issue is that if a subject is removed there can be problems resolving the identifier
    • Identifier mapping between the systems can be a challenge once the subject is removed from the downstream provisioned target

- Resolving a subject within Grouper

        • On the Grouper side, the subject should generally be resolvable -- the problem is mapping to a target
        • However, TomZ noted that even on the Grouper side, there can be issues, depending on when the change log fires
        • A full refresh / sync will catch that issue.
        • Also, Chris noted that using a hook to handle membership changes instead of the change log could solve this
            • Downside to using a hook is that two systems must be up and working properly -- could be too fragile

  - Possible Approaches to Real-Time Provisioning Challenges

        • Use customizable hooks that listen to the change log?
    • Have the identifiers for every member for every target stored in a table
    • i.e., the member table could have a column for each target system for every system that could be provisioned
        • Problem still occurs when a provisioned object does NOT have a one to one mapping between subject and identifier in the provisioned system
        • There was a use case from UBC where subject has 2 different corresponding provisioned objects (for example they have a person account  and a  super user account)
        •Might have to consider that sort of case to be an edge case we cannot immediately

- University of Washington's approach to provisioning membership changes

        • Jim mentioned that U-W has a hook that monitors membership changes -- a string gets written to activity file.
        • The U-W change file is targeted to provisioned systems
        • The LDAP identifier is same as subject ID identifier
        • Unfortunately not all Grouper sites use this standard way of handling identifiers

- Additional provisioning issues:

        • TomB noted that at SMM a question was raised about provisioning membership objects rather than group objects
        • When looking at provisioning from the change log, there is a group ID and a member ID
        • Does it make sense to cache the provisioned identifier based on the member ID?
        • Suggestion: use member ID to look up subject in the subject database
        • For performance reasons, does the look-up need to be done ahead of time and cached?
        • provisioned identifiers are a result of calculation of the Shibboleth attribute resolver, so need more data than is in the change log
        • need to use point-in-time data to get all the info needed for Shib to figure out the provisioned identifier
        • one option is to operate in full sync provisioning style and cache member identifiers
        • then maybe the current full sync method will be fast enough to be real time

Q: if there are 100,000 members and one is removed. How to handle that in real time? What happens in the LDAP target?
A: Can have a trigger based on the change log, search provisioned group for all members, DIFF them and make a change.

- Simple approach:

        • It makes sense to create a solution that works for the non edge cases
        • For the edge cases, errors will be generated that must be cleaned up, perhaps on a daily basis

        •  Use change log to pass a group and subject
        •  Use a DIFF approach
        •  If there is an error, wait for the nightly fix

- First step

        • Write/store the provisioned identifiers
        • To handle the provisioned identifiers of the group and the subject, use lookup approach first, then caching next if needed

[AI] (TomZ) will create a wiki page on steps to address real time provisioning.

Feedback from SMM

        • There was positive feedback at SMM about recently added Grouper features
        • Chris will work on UI for permissions, and that will help folks to grasp the permissions capabilities

Converting from Existing Groups Approach to Deploying Grouper

        • Penn State is interested in converting from their existing groups practice to Grouper
        • They are maintaining groups in LDAP directly
        • Need a conversion method to sync groups into Grouper
        • We've heard that conversion need before, including from sites that desire to move from an AD approach to a Grouper approach
        • The French Esup Portail group used web services to convert to Grouper
        • U. Chicago used persistent connections to the LDAP server so things got reflected to Grouper web services
        • U-Washington did something similar for converting to Grouper, using web services and an external process that ran every hour or so

[AI] (Jim) will create a wiki page showing a script for converting data from an existing approach when deploying Grouper
Grouper 2.0

        • Please review plans for Grouper 2.0 release. Start to be sure documentation is in shape

[AI] (Everyone) look at the Grouper 2.0 highlights wiki page and verify that the information is correct.

        • Chris will update the demo server when  Grouper 2.0 is ready.

        • Next call, hope to get an update from Rob on the Continuous Integration Server.

Next Call: Wednesday, May  11, 2011 at noon ET

Upcoming Meetings of Interest:

    • Getting Started With Grouper Seminar (the Sunday before Jasig), May 22, 2011

    • Jasig Spotlight on Open Source:

  • No labels