Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Grouper rules are configurable declarative scripts which run at certain times and perform actions on the registry.  They are similar to hooks though you dont have to write Java, and it does not require a change to a config file to enable a rule (i.e. anyone with authority in the folder hierarchy could enable a rule).

Use cases

Composite-ng: If an entity is no longer a member of the employee group, remove them from the group for application X

Disabled-date activation: If a student is no longer a member of the course X group, then add a membership to the course wiki group with end date in one week (note, this assumes that if the student is out of the course group, they fall out of the wiki group, another variation is to set an end date on an existing membership)

Composite-org: If an entity falls out of any group in the IT organization groups (meaning not a central IT employee anymore), then remove them from group X

Inherited permissions: If a group is created under folder a:b, then apply privileges to the group of READ,UPDATE to group a:security:admins

Rule structure

The rule structure is custom for Grouper since we want it to be performant and secure, however it is inspired from drools.  There are several parts to a rule:

  • actAs: subject that the rule will act as.  If blank, then it will be filled in with the user who created the rule (probably a bad idea since the person might leave at some point, unless it is a service principal).  There can be configurations in the which allow users to act as other users or GrouperSysAdmin.
  • check:  this is when the rule is fired.  This will generally have a checkType, which tells grouper when to fire the check, and some data which narrows down the search.  e.g. checkType could be flattenedMembershipRemove, and the data could be groupName: a:b:c
  • ifCondition: this might not be needed if the check contains all the information about when the rule should fire.  Otherwise you could put an EL here about something to check.  e.g.
    ${!RulesUtils.hasMember(groupName, subjectSourceId, subjectId)}
  • then: this is a scriptlet or maybe some built in actions.  e.g. thenType is removeMember and groupName is a:b, or a scriptlet:
    ${RulesUtils.removeMember(groupName, subjectSourceId, subjectId}

Rule data

The rule will be an attribute of a grouper object (group, stem, etc).  It will be specified as JSON.  We can have a screen on the UI which helps create the JSON, or we could split this up into multiple attributes if we like.  e.g.

    "then":"${RulesUtils.removeMember('b:c:d', subjectSourceId, subjectId}"


  • No labels