Grouper Users - Open Discussion List

[Chris Hyzer <>]

Right, everything/everyone changes eventually… Ive noticed that at I2 meetings J

 

Thanks,

Chris

 

From: Michael R Gettes [mailto:]
Sent: Wednesday, August 24, 2011 9:21 AM
To: ; Chris Hyzer
Cc:
Subject: RE: [grouper-users] question about Grouper permissions....

 

An org name that doesn't change... That is funny! :-)

/mrg

-----Original Message-----
From: Chris Hyzer []
Received: Wednesday, 24 Aug 2011, 9:18
To: Steven Carmody []
CC: Grouper-Users []
Subject: RE: [grouper-users] question about Grouper permissions....

>
> This, of course, leads directly to the next question -- does anyone know
> of any work that's been done with "naming" of permissions ? Any
> experience with how to represent a permission in a string ?

Well, you need to have be something that doesn't change, and a mapping strategy.  Either this means the permission name is hardcoded in the application, e.g. apps:whatever:permissions:canLogin, or it is based on another resources and its name which doesn't change, e.g. an org name: payroll:orgs:top:arts:engl.  There is a display name too, so the former can be "Can login", and the latter can be "English"

>
> >
> > Yeah, you would have to write a plugin, TomZ can give you more info.
> >
> > There are some complications with permissions though... since there
> > is allow/deny, and limits, and inheritance, it more complicated than
> > just a subject is in a group.  Notifications need to be tweaked in
> > 2.1 to take into account allow/deny.  And if ldappcng uses
> > notifications then the same is true there too.  Anyways, bottom line
> > is at this point the provisioning part of permissions is new
> > territory, though the existing components should work or will work at
> > some time soon, if you have examples to share that would help :)
> >
>
> As I'm sure you've guessed, my questions are less about a short term
> problem, and more about the long term direction.
>
> So, over the longer term, it sounds like the Notification/event log
> system will be able to report changes to the definition of a Permission.
> And code that's currently monitoring the event log for group membership
> changes could be extended to also look for Permission changes? And, by
> the 2.1 release you expect that events will "accommodate" allow/deny ?

Currently we support permission changes in the event log.  In 2.1 the plan is to support allow/deny in a flattened view.  Flattened means that only the effective differences are reported.  i.e. if you already had the permission by another path, it doesn't generate an event.

Thanks,
Chris