Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Draft Minutes: MACE-Dir-Groups 23-Feb-05

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Draft Minutes: MACE-Dir-Groups 23-Feb-05


Chronological Thread 
  • From: Shelley Henderson <>
  • To: Jessica Bibbee <>
  • Cc:
  • Subject: Re: [grouper-dev] Draft Minutes: MACE-Dir-Groups 23-Feb-05
  • Date: Tue, 08 Mar 2005 09:05:29 -0800
  • Organization: University of Southern California

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




Archive powered by MHonArc 2.6.16.

Top of Page