Dynamic authorization with gates

 Jspresso allows you to limit the access to parts of your application to users adhering to a specific role. Jspresso foresees to apply this type of authorization on about all elements of your application: properties, entities, (sub)views, actions,… The Jspresso Reference Guide fully explains this type of authorization.

 

We could call this type of authorization rules “static authorization”: A user is authorized to a part of the application depending on his role.

 

In some cases you might need a more dynamic type of authorization. Imagine for instance:

 

Employees can create and submit holiday requests. Once submitted for approval, the time sheet can no longer be altered.

 

Clearly here a more dynamic way of authorization is needed: Being authorized to edit an holiday request entity not only depends on the user’s role, but also on the state of the entity. Jspresso supports this kind of dynamic authorization with so-called gates. A gate is open or closed and can be associated to

  • Properties, entities and (sub)views: editable when the gate is open, read-only when the gate is closed. Gates can be associated to properties, entities or(sub)views via so-called "writabilityGates".
  • Actions: executable when the gate is open, the action can not be invoked when the gate is closed. Gates can be associated to actions via so-called "actionabilityGates".

Every gate refers to a so-called model that determines if the gate is open or closed. Jspresso comes with 2 predefined types of models:

  • The model is a string-property. In this case you can specify in Spring, via a regular expression on that string, when the gate is open or closed.
  • The model is an enumerated property. In this case you can specify in Spring, via a set of values out of the enumeration, when the gate is open or closed.

We give here an example of a writabilityGate that is open if the enumeration property state has the value "created" and hence will be closed for other state values (f.i. "submitted"):

<property name="writabilityGates">

  <list>

    <bean class="org.jspresso.framework.security.GrantedRolesGate">

        <property name="grantedRoles">

            <list>

                  <value>Employee</value>

            </list>

        </property>

    </bean>

     <bean class="org.jspresso.framework.binding.model.EnumerationPropertyModelGate">

          <property ref="accessorFactory" name="accessorFactory" />

          <property name="propertyName" value="state" />

          <property value="true" name="openOnTrue" />

          <property name="openingValues">

               <list>

                     <value>created</value>

              </list>

         </property>

    </bean>

  </list>

</property>

 

 

For instance, the above writabiligate could be included in an entity holidayRequest provided with an action “submit” that sets its property “state” from "created" to "submitted". Conclusion: The above writabilitygate specifies that only Employees are allowed to edit an holiday request, and only for requests in the state "created".

 

We invite you to do the test:

1)include the above snippet in model.xml in an entity that has an enumeration property called “state”. Alter the value of "state" and observe the impact. All the views backed by this entity will be impacted.

2/ transfer the above snippet on an entity property descriptor instead of the whole entity. Now only the field (and table cells) backed by this property will have the behaviour (editable <-> read-only) as described above.

3/ now transfer the snippet from the model.xml to the view.xml. Include it in a view on the entity. Only this view will be impacted.

 

As you could observe, the effect of the writabilityGate will automatically propagate: For instance, if a property is closed for editing, then this will be the case in all views displaying this property. As usal in Jspresso, you must specify things only once!