Goals

In refactoring some of the security event processing, we noticed that there could be some additional functionality with regards to how we define our conditions that make defining security rules more concise and powerful. The goal is to enhance the conditions processing in a manner that could not only be leveraged by security but other components as well.

Note the target of these enhancements are for more fine grained security configurations so we are not be using the template approach for these scenarios but templates could be written for these if desired

Proposal

Add support for contains

This support is mostly focused towards defining security rules where the authorization is based upon a list of users or groups where the GC keys of Request.Subject.groups or Request.Subject.roles could contain multiple values.

Currently method for defining security rules with authorization based upon the group.

## authorization rules
/config/handlers += [{
   "events" : "authorize",
   "handler" : "zero.core.security.authorization.AuthorizationHandler.class",
   "conditions" : "/request/path =~ /employees(/.*)?",
   "instanceData" : {
                  "groups" : ["group1", "group2"]"
   }                  
}]

What would be ideal is to define something as follows:

## authorization rules using the conditions clause to do regex matching on groups
/config/handlers += [{
   "events" : "authorize",
   "handler" : "zero.core.security.authorization.AuthorizationHandler.class",
   "conditions" : "(/request/path =~ /employees(/.*)?)  && (/request/subject/groups#? =~ (group1|group2))"
}]

Steve: "/request/subject/groups#? =~ (group1|group2)" represents a "contains" operator; the clause is true if any element of the list stored at /request/subject/groups matches the regex (group1|group2). The syntax needs to be reworked.

Note that regex gets very interesting here. The above scenario does not contain complex regex in the string values.

Add support for instance based security as events

This support is mostly focused towards defining security rules where the username or group name is included in the URI. When this was initially implemented we decided to special case a set of reserved words. In the example below we get access to the value of remoteUser inside of the event handler but it would be more useful to have it at the time of conditions evaluation.

Currently method for defining security rules with authorization based upon the the remoteUser.

## authorization rules
/config/handlers += [{
   "events" : "authorize",
   "handler" : "zero.core.security.authorization.AuthorizationHandler.class",
   "conditions" : "/request/path == /remoteuser/basicauth/{remoteUser}|"
}]

What would be ideal is to define something as follows:

## authorization rules using the conditions clause to do regex matching on groups
/config/handlers += [{
   "events" : "authorize",
   "handler" : "zero.core.security.authorization.AuthorizationHandler.class",
   "conditions" : "/request/path =~ /remoteuser/basicauth/(/request/subject/remoteUser == {remoteUser}) |"
}]

### extending it to groups with a little bit of the contains scenario mentioned above.

## authorization rules /config/handlers += [{ "events" : "authorize", "handler" : "zero.core.security.authorization.AuthorizationHandler.class", "conditions" : "/request/path == /remoteuser/basicauth/{remoteGroup}|" }]

What would be ideal is to define something as follows:

## authorization rules using the conditions clause to do regex matching on groups
/config/handlers += [{
   "events" : "authorize",
   "handler" : "zero.core.security.authorization.AuthorizationHandler.class",
   "conditions" : "/request/path =~ /remoteuser/basicauth/(/request/subject/groups #? =~ {remoteGroup}) |"
}]