The identification and authentication of a principal is highly configurable due to the standardization of the J2EE security manager. You can use LDAP, a database or a file as the container of principal information. Refer to your EJB Container manual for further details (Chapter 8, User management for JBoss).
The repository has two layers of access control. The method-layer is handled by the EJB Container and assert that certain methods can only be accessed by principals having a certain role. The configuration of this layer is based on J2EE. The second layer, the data-layer, is based on a Component's Access Control List (ACL) and is managed by each EJB. An ACL states which principals having what permissions and is incorporated in the subgraph constituting a Component. A simple but powerful schema is used to describe an ACL using RDF, which can also be extended to handle application-specific permissions. Currently only two permissions are handled by SCAM; read- and writepermission. Only positive permissions can be used, i.e. you can not exclude certain principals, only include them.
There are three principals in SCAM who have special meaning, the Administrator, the Guest and the Manifest owner. The role Administrator always overrides the access control meaning that he has permission to perform "everything". A Guest is a fictional principal which is used by unauthenticated users. If the Guest is included in an ACL it means that everyone has the given permission. An owner has always all permissions on all Components in his Manifest. A principal is considered to be an owner if his name is the same as the Manifest's identifier or if he has a role matching this identifier.
In the example above we see that 'kalle' is the owner of http://www.w3c.org/RDF/Validator (resides in Manifest 'kalle'), hence he has all permissions. 'olle', 'pelle' and the role 'teachers' can all access the Component, but only 'pelle' can alter it.
The actual names of Administrator and Guest are defined in scam.properties