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
PlayAuthApi provides access to the following services:
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.
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, 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:
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.