grouper-users - RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request
Subject: Grouper Users - Open Discussion List
List archive
RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request
Chronological Thread
- From: "Black, Carey M." <>
- To: "Hyzer, Chris" <>
- Cc: "" <>, "Blair Christensen" <>, Shaun Koh <>
- Subject: RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request
- Date: Fri, 10 Feb 2017 05:45:40 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; auckland.ac.nz; dkim=none (message not signed) header.d=none;auckland.ac.nz; dmarc=pass action=none header.from=osu.edu;
- Ironport-phdr: 9a23:ptGwexDYvO8YYqdKFI4XUyQJP3N1i/DPJgcQr6AfoPdwSPXyocbcNUDSrc9gkEXOFd2CrakV16yG7euwBCQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9GiTe5br5+Nha7oATeusQVgYZpN7o8xAbOrnZUYepd2HlmJUiUnxby58ew+IBs/iFNsP8/9MBOTLv3cb0gQbNXEDopPWY15Nb2tRbYVguA+mEcUmQNnRVWBQXO8Qz3UY3wsiv+sep9xTWaMMjrRr06RTiu86FmQwLzhSwZKzA27n3Yis1ojKJavh2hoQB/w5XJa42RLfZyY7/Rcc8fSWdHQ81fVTFOApmkYoUPEeQPIPpYoYf+qVsArxS+BBWjC+z0xzBSmnP72bc33/g9HQ3Y2gErAtIAsG7TrNXwLKoeX/24zK3SwjrfbPNawSr25ZbSfRA7v/6NXa97f83LxUUhCgjIiU6fqYj/MDyJ1eQBqXWX4/RuWO+0jG4nsBxxriKxycgxl4nEn4QYwU3K+yV+xYY6P9y4SEhjbN6lFptQqz+VN5FwQsw8X2Fkpjw2xaMbtp6meiUB1ZcpxwbHZvCZaYeE/g/vWeOMLTtlmX5ofby/ihmu/US8z+D8WNe73VlLoydAl9TBtG4B2wLL5sWFRfZx5Fqt1DmT2wzJ5OxIP1o4mK7FJ5I5zL4/iJkevVjGEyLzmEj5kLOZdksh9+S25OnqY6jpq5qTOoJ0iAzzPKEjldCkDusjKAcDWXWQ9/6m273550L5Ra1Hjv0onandt5DXPdwVq7K+DQNJzIov8guyATG43NgBmnkIN0xKdAiAj4j0J1HBO/f4Deq5g1uxijtr3+rGPrr9AprTMnfDjLbhfbF760JGzwoz0Mxf55ZTCrEGI/L/QFP+tNvdDhMhMgy0xfjoCMll248AQ22DHrKVPabPvVOV++4iJueMaYAJtDrhLvUl6eDhgHA4lFIYeKSk34UbZG6gEvRjOUqZYH7sgtkbEWcNuwozVPfliFmYXjFPZHa+Rb8w6i81BY+9CofDXZ2tjKaf0yimA51afnpGBUyUEXf0a4WEXO8BaC2IIs9mjzwETaauS5U42RGzrw/11aBnLvHP9y0ctJLjz8R15/bNmR0o9Dx0Cdid3H+XT2FygGwIWyE60LphrkNg11fQmZR/1rZ4BM5e/bcBeQcgNIWWh7h/ANDjSA/bVtaSQxC7WtigB3c8Qs9nkPEUZEMoUf+mhxvAm2KBCqUYhvSuQtZ8pqjY1nPyYZ8nkF7Bz7RnglU7FJgcfVa6j7JyolCAT7XClF+UwuPzLfwR
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Chris, First, thanks for the write up. I think you captured the ideas very well. I am not “sold” on the labeling as “attestation”. It is an accurate word that does describe the concept. But I am not sure that is the most obvious word to use
in a UI/attribute names. I see that the design is to apply these equally to folders and groups. ( I am not sure if there would need to be slightly different workflows/processes for the
two types of attestations.) Folders would be to verify what about the folder? ( my answers: Just the top level folder itself? Just groups in one level down from the folder?
all sub folders and all sub groups?) Groups would be to verify what about the group? ( my answer: All memberships in the group ) Maybe something like AllMembersValidation instead for group entities? ( I know it is longer. Is there a length limit?) GroupValidation (if only for the group object, as opposed to the attestation of the members of
the group done by the AllMembersValidation ) FolderValidation (if only for a folder object) But maybe I am overthinking or over constraining how these attributes would be used? A few other questions: 1 ) Do you expect to have a default implementation for “Daemon
should run daily (via cron)” or is that planned to be an exercise for the implementers? 2 ) If this part remains a “future scope” (“If attestation is not done in a certain amount of time, disable the memberships or group somehow”) then maybe a similar
cron daemon could also be crafted? or is the issue the “disable the memberships or group somehow” does not exist yet? If so, then maybe some “hack around” could be used like creating
a “failing attestation” group that members could be added to until they are “attested” to again? ( I am thinking of a group who’s membership would be subtracted from the membership of the group needing attestation. …
Maybe another attribute “grouperAttestationExpiredGroup”
“to point to the group to use for this function” to auto add memberships at the expiration point, and auto remove when the membership is “attested” again.) Also as part of the original description: “to know when the owners have last reviewed or updated” Should the attestation date be auto set when the object is updated? That way an active management of the group would never trigger the attestation process directly because it is being cared for
in a BAU (business as usual) way. Or maybe there should be an attribute of AutoAttestationOnUpdate=Boolean , so that option would exists too. --
Carey Matthew From: [mailto:]
On Behalf Of Shaun Koh Hi Chris, That is awesome and yes, it meets our requirements. – our Security team and the Grouper PM are delighted, thanks ! Best Regards, Shaun K. From: Hyzer, Chris []
Does this capture what people had in mind? https://spaces.internet2.edu/display/Grouper/Grouper+attestation Thanks, Chris From: Black, Carey M. <> Another approach to “email till validated” would be to treat the group as “expired” at a “date”.
Like a user’s membership in a group can expire, maybe the whole group could be expired? ( So any query of membership for the expired group would return an empty set.) I would not want to “drop”(delete) the group or the members memberships, but rather, just have the group “not able to be used” until it is certified again. Sometimes sending email is not enough… Sometimes, you actually need to “turn it off”. Might also be a good way to “time lock” multiple memberships. (expire a group-C that is a members of another group-B, instead of setting the expiration date
on all the “right” Members of group-B.) That way you could set it in one place and effect all of group-C being in group-B. To make extensions/early retirement easier. --
Carey Matthew
Office of the Chief Information Officer (OCIO) Identity and Access Management – Security Engineer-Lead 614-292-6079 Office From:
[]
On Behalf Of Shaun Koh Hi Chris, What you’ve outlined seem to work for us though we would prefer the emailing to be an optional flag. Also, a secondary filter would probably be handy to filter grouping of groups with the recertification flag set. – e.g. to view the recertification status for
all groups within a specific stem or group Let me know if the above made sense. Best Regards, Shaun K. From: Blair Christensen []
We've had a couple of requests @ uchicago for that precise workflow. On Mon, Jan 23, 2017 at 7:33 PM, Hyzer, Chris <> wrote: How would that work? -
Configure a group or stem with a number of days that groups need to be recertified -
When that time elapses email the admins of the group or a specified list every day until it is done -
Have a button in the UI to mark the group as recertified Thanks, Chris From:
[mailto:]
On Behalf Of Shaun Koh Hi there, I am wondering if there was any thought of having an audit trail for group verification/recertification ?
In particular, we currently have some high risk/value groups that we would like to know when the owners have last reviewed or updated (and perhaps send them a
friendly reminder when required). Is this something that you may be interested to implement ? – or does this feature exists and that I am just not aware of Best Regards, Shaun K. |
- Re: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request, Hyzer, Chris, 02/08/2017
- RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request, Shaun Koh, 02/08/2017
- RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request, Black, Carey M., 02/10/2017
- RE: [grouper-users] RE: Group Verification/Recertification Audit Trail -- Feature Request, Shaun Koh, 02/08/2017
Archive powered by MHonArc 2.6.19.