[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

Similar issues:
KULRICE-12147Difficult to access buttons in Authorization examples
KULRICE-8124KIM rules are extending the KRAD DocumentRuleBase
KULRICE-12841Does KRAD/KRAD-DATA support extended attributes on documents?
KULRICE-8975KRAD AuthZ does not have hooks for actions based on failed authorization
KULRICE-12018KRAD Library Table of sample extends framed content area
KULRICE-9478KRAD Controllers are always transactional
KULRICE-2416all rice actions should extend KualiAction, so these permissions are enforced - they replace any existing app constants or configuration related to rice authz - please double check for any i missed
KULRICE-10803KRAD Demo Labs Lookup refactoring
KULRICE-8282Create new krad Smoke Tests for those that extend UpgradedSeleniumITBase and don't yet have a Legacy version
KULRICE-8385Create new travel Smoke Tests for those under edu.samplu.travel krad and test validationmessagesview that extend UpgradedSeleniumITBase and don't yet have a Legacy version
Rice Module:
KRAD
KRAD Feature Area:
UIF MVC
Application Requirement:
KS
KAI Review Status: Not Required
KTI Review Status: Not Required

 Description   

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{

@Override
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;
}
}



 Comments   
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 Wed Jul 15 18:25:47 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.