Grouper can limit a permission to a condition in the environment or data passed to Grouper. Note, limits can only apply to permissions which are allowed, not disallowed.
A limit is an attribute of type limit assigned on the permission assignment, or assigned to the role membership, or assigned to the role, or permission definition. Note: I think we could do something by permission name by assigning to the permission definition and checking the permission name in the environment (or we would need a way to assign an attribute to an attribute name).
At runtime, Grouper, or custom logic, or the caller of the API or WS could set environment variables for the request that the limit logic can use.
At first, there will not be a helpful UI, but there will be an expression language (EL) where things will be possible :)
For instance, a built-in limit expression language could be (note, you set the Root folder where Grouper creates built in things, in this case it is school:etc):
school:etc:limits:expressionLanguage
-or- if you want to make sure the environment variables are always passed in (or would not be allowed):
school:etc:limits:expressionLanguageVariablesRequired
When it is assigned, the value could be:
${amount <= 50000}
Those limits would take the environment variables available to the limit, and put them as EL variables.
There could be helper classes to do common things (in this case no arguments are required)...
${grouperHelper.hourOfDay() >= 9 && grouperHelper.hourOfDay() <= 17}
Or here the caller passes the user's ip address (ipv4 still :) )
${grouperHelper.ipOnNetworks(ipAddress, '1.2.3.4/24, 2.3.4.5/26')}
In the grouper.properties you could configure other helper classes that are in scope in the expression language
In the grouper.properties you could associate custom limits with an implementation of a Java interface to take the environment variables, the value of the limit attribute, and other data about the calculation, and give an answer.
We need to work on the UI for this... so users dont have to enter in their own EL :) Maybe the answer is EL is for technical people, and regular users can use common limits that are more friendly. Or we need a lot of documented examples :)
If there are errors, I would assume an exception will be thrown so the caller can see what is going on without looking in the server logs.
It would be nice to be able to set environment variables on the UI (maybe 2.1?)
sdaf