Ripla

Rich Platform project for Java web applications.

This project is maintained by aktion-hip

Permission Service

A Ripla application is a dynamic system. Bundles providing business logic or visual aspects to the application can emerge or disappear during the application's life time. Therefore, it's impossible to define a system restricting the access to resources up front. Instead, use case bundles have to be given the possibility to define permissions to protect aspects of their functionality themselves. Plus they need the possibility to notify the system about the permissions they define.

This is where org.ripla.services.IPermissionEntry comes into play. By implementing service providers for IPermissionEntry, bundles can define permissions and register them to the application’s permission registry.

Note: the Ripla permission service collaborates with the OSGi user admin service (see User Administration Service). In OSGi user admin wording, the permission is equivalent to an action group.

public interface IPermissionEntry {
    String getPermissionName();
    String getPermissionDescription();
    String[] getRequieredMemberNames();
    String[] getMemberNames();
}

IPermissionEntry.getPermissionName() returns the name (i.e. ID) of the permission. A use case controller can further on refer to this permission when implementing the AbstractController.needsPermission() method (see Use Case Controller Class).

IPermissionEntry.getPermissionDescription() returns the pemission's description, i.e. some information about the resources protected by this permission.

IPermissionEntry.getRequieredMemberNames() returns the set of required members (String array) of the group created with this permission name. If a resource is protected by this permission, i.e. the controller needs this permission, a user must have one of the specified roles (i.e. has to be member of all of those groups) for that he is authorized to access this resource.

IPermissionEntry.getMemberNames() returns the set of required members (String array) of the group created with this permission name. If a resource is protected by this permission, i.e. the controller needs this permission, a user must have one of the specified roles (i.e. has to be member of one of those groups) for that he is authorized to access this resource.

Example

In the Demo application, the skin select action is protected for that only admin users can access this functionality. This protection is implemented as follows:

public class PermissionEntry implements IPermissionEntry {
    public String getPermissionName() {
        return "config.skin";
    }
    public String getPermissionDescription() {
        return "Permission to select the skins.";
    }
    public String[] getRequieredMemberNames() {
        return new String[] {};
    }
    public String[] getMemberNames() {
        return new String[] {"ripla.admin.group"};
    }
}

This examle registeres a permission with the name "config.skin" and states that every user of the admin group has this permission. The following controller refers to this permission to protect the resource it controls:

@UseCaseController
public class SkinSelectController extends AbstractController {
    protected String needsPermission() {
        return "config.skin";
    }
//...
}

The controller class states that it needs the pemission "config.skin". This way, only users that are member of the amin group will be able to access the resouce controlled by this class.