• Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: Backlog
    • Component/s: Security, User Interface
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Rice Module:
    • KRAD Feature Area:
      UIF MVC
    • 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 =;

      //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;



          lsymms Larry Symms added a comment -

          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

          lsymms Larry Symms added a comment - 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


            • Assignee:
              depstein Daniel Epstein (Inactive)
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: