Grouper Developers Forum

[Shelley Henderson <>]

Is there a MACE-dir-groups call now? I can't find an email with
conference call info.

Shelley
USC

Jessica Bibbee wrote:
> MACE-Dir-Groups Conference Call
> February 23, 2005
>
> *Participants*
> Tom Barton, U. Chicago (Chair)
> John Ballem, Brown U.
> Blair Christensen, U. Chicago
> Gary Brown, U. Bristol
> Minh Nguyen –Stanford U.
> Brenden Bellina, USC
> Steve Olshansky, Internet2
> Jessica Bibbee, Internet2 (scribe)
>
> Carry-over *Action Items*
> [AI] {Blair} will rework and update the 0.6 feature prioritization
> list into additional 0.5.x releases, the initial 0.6 release, and
> future 0.6 releases
>
> *Discussion*
> The table of features slotted for Grouper releases up to and including
> 0.6 is still in progress. Another item for consideration is changing
> the UI – there should be the ability to view groups recently modified
> for a particular user. - This refers to groups that have been recently
> modified by the logged-in user.
>
> The Group discussed the relevancy of logging requirements to the
> Grouper API, and actual use-case scenario-driven examples that might
> emerge on a campus. It is the intent to provide better diagnostics and
> messages for logging requirements, and might factor into both
> exception logging and error handling. If exceptions are presented at
> the run time, it may not be necessary to have certain types of
> diagnostics in the log. The UI is capable of displaying the apposite
> messages to use or alternatively take actions, based on the type of
> error. There is another question of what information do we decide to
> log, given that it will be useful for purposes of debugging in the
> event of a problem. The logging facilities currently in the API are
> minimal, only assisting with debugging problems, - but is not thorough
> in listing the various types of information that would be most
> valuable. This could be made up for with the insertion of appropriate
> logging codes.  - Define a standard around levels for the bugs,
> information, versus the errors. It would be up to you whether to log
> at a higher or lower level. This may or may not carry an aspect that
> pertains to history, depending on the type of logging requirement –
> audit or accounting, for example. The question of what information
> should be logged might easily be addressed by looking at how people
> need to rely on logs.
>
> {John} shared an example, where Brown University has set up a system
> of 2 separate tables – one for events and another for audits. For the
> event tables, you can log a batch event and whether there is a
> successful finish or not, which decides whether a warning is given.
> The audit log is essentially about attribute changes – add, delete,
> etc. This keeps things simple, and has worked out satisfactorily up
> until now. One problem with the current API is that there are no
> textual messages appearing when an error is performed – for example,
> you try to delete a Grouper group, but there are still members there.
> An error has occurred, but there is no way to look up what happened,
> as it is not in a log. Brown's provisioning system uses an LDAP
> registry and makes daily changes, accounting for web logging of
> objects and attributes. It has proven useful to have a unique run ID
> for each job, so that it is possible to view the start and finish of a
> thread – or where it has not finished yet. This provides tracking and
> accounting information regarding when people enter and exit the
> environment. Any information modified – telephone numbers,
> departments, affiliations – is logged daily. Whether or not this is
> strictly applicable to Grouper is not yet defined, but it appears to
> be of use from a trouble-shooting standpoint. Metadirectory changes
> are reflected in the audit log, while the event log lists when the job
> was ran, who ran it, and whether or not it successfully completed. Did
> any warnings or errors show up? The bottom-line questions, whose
> answers would be most useful, include: 1) who is making the change? 2)
> what is the change? and 3) when was this change made?
>
> In the Grouper log, it might be advisable to log the session ID; in
> this way, it will be possible to distinguish one session from another,
> when multiple sessions are running simultaneously. It may not be
> necessary to track the servlet sessions as well, as these will be more
> unique. However, indexing from the UI might be a desirable option.
>
> {Minh} expressed a situation at Stanford when presented by a problem
> within a web application. It is difficult to associate the lines of
> log to a specific user's session. It would be useful to have the
> capability to track events within the web application, not just within
> Grouper API. Would it be useful to have the Grouper log separately, or
> might they be useful cooperatively? Information for loaders would also
> prove useful – such as ensuring that run time errors are justly
> reflected. Additionally, if one could draw stats of a particular
> loader – how many affiliations, titles, etc. were changed – from
> within that application. The question is whether or not a session
> should log every change that is made, for recovery purposes. The
> differences between immediate changes and the effective outcome should
> be clarified. There is a process that evaluates the effective change,
> and perhaps it should reference the original session in which that
> change was made. It is important to keep the framework simple, and
> this might be a challenge if you are trying to track large groups.
>
> Grouper audit style logging is different than a typical application
> when looking at the effective membership. We should identify which
> information is needed to be logged in which way. Is there a need to
> audit events or changes to privileges such as knowing which subject
> has which privileges within Grouper or within Signet? A snapshot could
> be set up each time there is an update, which would provide a view of
> that row and then display those user privileges in a table.  People
> have the capability to use external providers, outside the context of
> grouper, even though the privileges come internally. For example, a
> site might provide alternatives (SPOCP, etc) to Grouper's built-in
> privilege persistence mechanisms. As it is not a set standard, it
> might be all one could suggest to track the activity on Grouper's
> privilege or abstract interface. If we focus on using Grouper's
> internal privilege implementer, it would advocate having the
> appropriate audit logs, as others have.
>
> Granting of privileges could be done via the API or the UI, like a
> bi-directional to an internal management system. It might be an option
> to simply require the interface to indicate that the external system
> should log the history of privileges, but it would need to do so at
> run time – something Grouper does not require at this point. There
> seems to be sufficient interest in agnostic application level logging,
> for the general application. Should only the immediate changes be
> logged, or should there be the option to log the effective?
> Consideration should be given to factors such as structural changes to
> the subgroup hierarchy or other subgroup combination. A log processor
> could model these changes of the effective membership, but it would
> require sufficient information to do so. Considering the quantity of
> data that could theoretically accumulate, it might be necessary to put
> a cap on the length of time that the data is stored. The Group should
> take these ideas back to each of their own departments to 1) reflect
> on how this might be applicable to their needs, and 2) what are those
> needs specifically? This discussion of how AuthN and AuthZ might
> actual unfold within Grouper should be continued in a future call.
>
> The next topic of discourse centered around preserving privacy of
> forward referenced membership information in LDAP. {John} detailed the
> 2 items that he would like to see happen initially within Grouper –
> provisioning of bulk mailing and (using ismemberof for) AuthZ. He
> described how Brown U. is testing for all the groups that need web
> AuthZ. There is a list serve for those effective groups' memberships
> to do the bulk mailing; it might be better to use static groups to
> replace some of the bulk mailers. How would we envision the delegation
> of this, given the complexity associated with large numbers of groups,
> versus the ease of provisioning LDAP attributes with the groups. You
> can view the delegation of multiple attributes versus the hierarchy or
> groups with a little more complexity. How does the Group feel about
> this approach? Another item to consider is what happens with a small
> group, such as a club. In Brown's model, you have to open that
> attribute in all the groups – and would have access to see all the
> groups. As Grouper deployment becomes more prominent, this raises
> questions about privacy.
>
> There are more options open for static groups. How would a sub-entry
> style of approach work? There are fixed privilege practices and could
> also tag memberships with who can read, for example – directly out of
> Grouper. If there is a single ismemberof value in the sub-entry –
> groupview or membershipview – the directory would be allowed to look
> at the sub-entry information, and allot only identified principles to
> see the corresponding memberships. There could be problems in the
> provisioning, as some might have rename issues, etc. Any provisioning
> system you make would have to delete all the entries and create as you
> go. The proposal for sub-entry is in the context of a person tree. In
> terms of implementation, try to manage privileges within Grouper as
> much as possible, and the presentation in LDAP is simplified as well.
> The number of groups could grow substantially, for example – keeping
> ties with alumni – and the associated problems with size grow as well.
> Ultimately, a fine-grained access control is preferred over person
> expressed memberships. – Think about a smaller set of privilege set
> classes and how to simplify within an LDAP context. An alternative
> might be a value-based access control. {John} mentioned that this
> might call for some testing of the sub-entry strategy.
>
> Before the next release of Grouper, the code needs to be gone through,
> and the Group should consider including a demo that will provide a
> view of what the final will look like, even if it is not yet finished.
> The next revision of Grouper is expected to be available by the
> Internet2 Spring Member Meeting in Arlington Virginia
> <http://events.internet2.edu/2005/spring-mm/>. The upcoming NMI
> release will be here near the end of April; the last release did not
> include a CD for Grouper, but did provide an opportunity for
> visibility of Grouper v0.5 <
> http://www.nmi-edit.org/releases/index.cfm>.
>
> The next MACE-Dir-Groups call will take place Wednesday, March 9, 2005
> at 12pm ET.

Attachment: signature.asc
Description: OpenPGP digital signature