Here are some high level requirements. More detailed user stories are listed on Authentication and Authorization User Story Summary.
- Role-based access control. Optionally, roles should be retrieved from configured directory service (e.g. LDAP).
- User-based access control. A curator should be able to deny any access to the rest of the users on a particular collection object she is working on.
- Attribute level access control. This may not be a norm but it is possible to envision an access control policy where certain field of an object (e.g. loan) is not visible to users in certain role(s).
- Performance of search should not be degraded beyond certain percentage (req?) if attribute level access control is enforced.
- If a user does not have read access to a resource then relevant objects of that resource should not be listed in the result set of search or index operations on that resource.
Following are the options we should evaluate for possible authorization service considering the CollectionSpace specific requirements listed above.
Nuxeo Access Control
- Managing authorization is very easy as authorization policies are associated with each document and inherits from parent documents
- Authorization policies are extensible by means of adding just new ACEs (access control entry)
- With Security Policy extension point, it is possible to plugin custom security policy at a global level in addition to document level settings. This could be useful to apply additional security constraints on search operations and/or on document properties?
- Resource to protect: Document repository and its artifacts. That means Nuxeo authorization could not be used as a generic authorization service where resources to protect could be methods on classes/objects, objects, URIs and HTTP actions (RESTful web service end points) or UI resources (widgets, etc.). It seems like a fundamental assumption in Nuxeo Access Control is that the resource to protect access has to be an artifact (document) stored in the Nuxeo repository. The access control policy resides with the document as one of its system-defined document type. This is evident from the following :
- Document Security "In Nuxeo, each document has a collection of security entries that allow or disallow actions to be performed on the document"
- Security Model "Inside the repository each single document can have an ACP. By default security descriptors are inherited from their parent, but inheritance can be blocked when needed."
- The following code
- Authorization depends on having NuxeoPrincipal in the security context. NuxeoPrincipal is only inserted in the context by various Nuxeo authentication providers as described here. That means that Nuxeo Authorization is not an independent service.
- Based on the 2-server deployment of CollectionSpace services, access control check would be a remote Java call from cspace domain to the nuxeo domain. This could be expensive considering how frequently this call would be made.
From "A brief introduction to XACML"
At the root of all XACML policies is a Policy or a PolicySet. A PolicySet is a container that can hold other Policies or PolicySets, as well as references to policies found in remote locations. A Policy represents a single access control policy, expressed through a set of Rules. Target is a set of simplified conditions for the Subject, Resource and Action that must be met for a PolicySet, Policy or Rule to apply to a given request. If all the conditions of a Target are met, then its associated PolicySet, Policy, or Rule applies to the request.
- Flexible access control policy model. Resource+Action could easily satisfy CollectionSpace's requirements regarding resources to protect.
- Clear separation between decision point and enforcement point.
- Non-proprietary: Industry standard (now in 3.0) being defined by OASIS with the help of several security software infrastructure vendors.
- Lack of reliable implementations in opensource world. SUN has reference implementation. JBoss XACML seems to be using SUN's RI. It is not known how widely XEngine is used. It also not known how actively it is managed.
- Performance. Access control checks could be made quite frequently. According to XEngine, SUN's RI is very slow. However, it is also not known how reliable XEngine is.
- File-based policy store. Both SUN RI and XEngine see to be using XML file based policy stores. It is hard to provide management interface to file base store (lack of transactions, locking, etc.). Search, Gets and Updates are difficult.
- Lack of XACML policy editor as well as management and administration interfaces.
Spring Security 3.0 (formerly Apache Acegi Security) is a comprehensive security solution. It is a widely used, stable and mature enterprise security solution. Following features are relevant for CollectionSpace security.
- Authentication Service
- HTTP Basic, Digest and Mutual Authn using X509 certs
- Single sign on using CAS
- Open ID support
- Backend: LDAP, Database,XML file, properties, etc.
- Channel security with HTTPS
- Authorization Service
This page discusses Spring Authorization Service only.
Spring Authorization Service
Here are the features relevant to CollectionSpace.
- Spring security's UserDetailsService provides a way to plug in tenant specific association for the user into the security context. This information could be represented as GrantedAuthority.
- Domain Object instance security allows to create ACL (ACL_OBJECT_IDENTITY) for an object of a class. The access control check is supposed to be fast as permissions are represented as 32 bit integer mask. This should satisfy collection object instance level security for example.
- JSP Tag Library for access control from JSP-based UI
- Simple expression based access control on web requests (URI), method invocation (with pre/post annotations) and object identity. Spring authorization expressions are good enough for CollectionSpace.
- Spring security namespace allows to externalize web security and business object (method) security expressions in XML. However, it would be great to put policy expression in database.
- Security policy in the application logic (using annotations or direct expressions) should be avoided by utilizing Spring namespace.
- Investigate if we could use user management provisioning APIs.
Advantages (see Spring Security Features):
- Widely used enterprise class authorization infrastructure in available in Java.
- Simple and easy to understand data model.
- Pluggable architecture (UserDetailService, LDAP, OpenId, CAS, OAuth, etc.)
- Wide array of options (Java APIs, JSP tags, Spring expressions in XML, etc.) available for access control.
- Built-in session management
- Allows to vote on access decision
- Might require Migration of code from JAAS based CS Identity Provider to UserDetailService of Spring
- Can tenant be represented as GrantedAuthority?
- Allows to insert security policies (roles and permissions) in business logic.
- Lack of management interface (MBeans) to perform CRUD on roles and permissions
Notes on Spring Security :
- Spring's JaasAuthenticationProvider could be used to reuse the CollectionSpace Identity Provider, a JAAS based LoginModule. However, user-tenant association retrieval is simple enough to be retrofitted into the Spring security framework.
- Check out user management provisioning APIs