[KULRICE-8782] KRAD AuthZ is difficult to extend Created: 17/Jan/13  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Security, User Interface
Affects Version/s: 2.2
Fix Version/s: Backlog
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Major
Reporter: Daniel Epstein (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Rice Module:
KRAD Feature Area:
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required


We had a requirement in KS to have authorization based on some custom permission details and logic defined in a custom permission type service. We did not want our custom permission type service to be used by all the other possible modules in the system, so we had to copy each KRAD KIM TYPE and attributes to new ones, update the spring context with our new permission types, copy the KRAD permission templates and extend ViewAuthorizerBase, copying the isAuthorizedByTemplate, canOpenView, and canEditView methods, and change only the template name and namespace to match our new template.

One possible solution:
Since permission details contain a KIM TYPE field (right now does not seem to matter what goes in there), it would be easier for developers to configure a permission with a new detail where the detail's KIM TYPE defines the custom permissionTypeService that matches that specific detail. In this way, you would not have to touch the view authorizer or the templates, just configure a new KIM TYPE with a custom permissionTypeService, and add that detail to the permission that uses the existing KRAD permission template.

the ViewAuthorizerBase could also be changed so there are simple hooks to configure the templates that it checks.

We ended up adding a permission type service that matches based on spring expression language, which ends up being very powerful and easy to configure (although there are some performance concerns)

public class KsViewPermissionTypeService extends ViewPermissionTypeServiceImpl{

protected List<Permission> performPermissionMatches(Map<String, String> requestedDetails, List<Permission> permissionsList) {
//Use the superclass to do normal matching
List<Permission> matchedPermissions = super.performPermissionMatches(requestedDetails, permissionsList); //To change body of overridden methods use File | Settings | File Templates.

//Loop through the matched permissions
for(Iterator<Permission> iter = matchedPermissions.iterator();iter.hasNext(){
Permission permission = iter.next();

//Check if the permission has the 'permissionExpression' attribute. If so, evaluate the expression
if(permission.getAttributes().containsKey("permissionExpression")){//TODO change the name of the attribute
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression(permission.getAttributes().get("permissionExpression"));//TODO cache the expressions

if(!exp.getValue(requestedDetails, Boolean.class))

{ //If the expression resolves to false then remove from the list of matched permissions iter.remove(); }

return matchedPermissions;

Comment by Larry Symms [ 26/Jun/13 ]

would like some eyes on this for 2.3 but don't want to risk 2.3 timelines so if the fix requires significant time reschedule for 2.4

Generated at Sun Sep 20 17:50:09 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.