The Flexible Extensible Digital Object Repository Architecture aka Fedora Repository uses XACML based policies for authentication and authorization. XACML is an XML based policy language that is used to define access control lists and secure applications using a standard policy based approach.
The latest release of Fedora 3.6.2 promotes the JAAS based FeSL as the default security layer. FeSL which was introduced in 2011 is designed to improve upon the legacy XACML based security scheme that has been Fedora's backbone since its release. While FeSL simplifies security, XACML still retains its relevance in terms of managing and setting up access to the API-A and API-M interfaces. The API-A interface provides a read-only access to the repository's properties and its objects. API-M on the other hand enables management of the repository and allows edit access to the contained objects.
The latest release of Fedora 3.6.2 promotes the JAAS based FeSL as the default security layer. FeSL which was introduced in 2011 is designed to improve upon the legacy XACML based security scheme that has been Fedora's backbone since its release. While FeSL simplifies security, XACML still retains its relevance in terms of managing and setting up access to the API-A and API-M interfaces. The API-A interface provides a read-only access to the repository's properties and its objects. API-M on the other hand enables management of the repository and allows edit access to the contained objects.
While Fedora ships with a basic set of XACML policies that provide a basis for securing access to the two interfaces, there will be scenaros when authoring a custom policy will be required. When attempting to write the policy writing guide is a good place to start. XACML policies are rule based and generally enforce either an PERMIT or a DENY result to a specific resource. Apart from these two results, there are the the Not Applicable and the Indeterminate results too.
When attempting to understand the application of the policies and the final results that are generated, the two key points to take away is that the DENY rule supercede's the PERMIT rule. For example, if an administrator is PERMITTED to access the API-A interface but there is a DENY rule on a specific API-A operation that applies to all users including the administrator, then the administrator will not have access to that specific operation.
When attempting to understand the application of the policies and the final results that are generated, the two key points to take away is that the DENY rule supercede's the PERMIT rule. For example, if an administrator is PERMITTED to access the API-A interface but there is a DENY rule on a specific API-A operation that applies to all users including the administrator, then the administrator will not have access to that specific operation.
Secondly, access to a resource has to be explictly granted. For example, if there is a DENY rule that limits access to the API-A interface to all non-admin users, it does not explicitly imply that administrators will be able to access the API-A interface. There has to be a PERMIT rule that gives them that access. Thus, while designing policies, do remember to check out section 3.3 in the policy enforcement guide. It might save you hours when you are trying to figure out why a certain user cannot access an interface !!
