Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] question about Grouper permissions....

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] question about Grouper permissions....


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Michael R Gettes <>, "" <>
  • Cc: "" <>
  • Subject: RE: [grouper-users] question about Grouper permissions....
  • Date: Thu, 25 Aug 2011 05:58:53 +0000
  • Accept-language: en-US

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




Archive powered by MHonArc 2.6.16.

Top of Page