Overview

The insign Play Auth provides functionality to manage essential information about parties (people and organizations) and about security policies (permissions and roles).

The central point of access to the PlayAuth API is ch.insign.playauth.PlayAuthApi. The PlayAuthApi provides access to the following services:

  • AccessControlManager — provides methods for access control discovery and permissions assignment;
  • PermissionManager — retains information about defined and assigned permissions, provides tools to create & transform permissions;
  • EventDispatcher — dispatches module events and provides methods to add or remove event listeners;
  • PartySerevice — provides methods to create, retrieve, update and remove parties;
  • PartyRoleManager — provide methods to create, retrieve, update and remove party roles;

The PlayAuthApi also provides methods for authentication, impersonation, retrieval of a currently authenticated party's info; it also has shortcuts to some methods of the AccessControlManager.

How It Works

Play Auth operates with the access control lists (ACL) which define what is allowed or denied to do. ACL consists from the following fields:

  • source type - type of the object that would request access to the target of the ACL.
  • source ID - ID of the source object.
  • target type - type of the object which would be managed by ACL.
  • target ID - ID of the source object.
  • allowed actions - list of permissions that are allowed to source object to do over the target object.
  • denied actions - list of permissions that are denied to source object to do over the target object.

Source type, source ID, target type and target ID could be defined explicitly or set "*" which would say that this ACL is applicable for all. This is useful if it's required to set default permissions for all users or groups.

Default Play Auth ACL implementation restricts all permissions from anyone if there no ACLs configured. By creating ACLs defauld behavior would be overriden. ACL's also could override each other. Play Auth resolves such situations by checking java class hierarchy. For example if we deny Party (interface that all classes that treated by users should implement) to access admin backend, but allow it for some custom class called model.Admin which would implement Party imterface as well then for all Admin objects last one would be used.

General flow of ACL resolve described on following diagram:

acl_inheritence

If narrow ACL doesn't override one ore more of the permissions from the wider ACL these permissions would be inherited. So, if we have set permissions User class and didn't set them for Admin they would be inherited as is.

The most common sources of the permissions are Party and a Group. Party is the representation of the person registered in Play Auth, while the Group could be treated as the set of the permissions that could be assighed to Party. Play Auth knows that Party could be assigned to Group so it includes into it's ACL hierarcy Group permission as well.

  1. Apache Shiro - Official website
  2. Apache Shiro Reference Documentation
  3. Java Authentication Guide with Apache Shiro
  4. Java Authorization Guide with Apache Shiro
  5. Party archetype pattern - Chapter 4.3 from book Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML