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: Steven Carmody <>
  • Cc: Grouper-Users <>
  • Subject: RE: [grouper-users] question about Grouper permissions....
  • Date: Wed, 24 Aug 2011 13:17:46 +0000
  • Accept-language: en-US


>
> 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