Object-Level Security (OLS)
Object Level Security (OLS) provides the following functionality:
• Filtering of objects returned from BOM queries
• Permission checks on updates to object attributes
• Storage of object delete permissions
To use OLS for a class you must render the class in OCC with security enabled. Security is enabled by checking the box on the security tab of the class. No permissions will be enforced for classes that are not rendered with security enabled.
The primary purpose of OLS is to filter the results returned from BOM queries. This is done in the BOM by checking permissions for the Subject associated with the thread security context. The Subject is associated with the thread by setting the Subject on the OWEvent used to call the initial rule. The Subject is carried forward for any rules called from the initial rule. Client code must get an authenticated Subject and set it on OWEvent parameters used to call rules.
The behavior of the BOM is as follows:
• When performing a getObject query for a single object (like a query by key), the BOM checks the permissions on the object and the object does not return if the Subject does not have the right to read the object. This throws an ObjectNotFound exception if you did the query with that option enabled.
• When performing a getObjects query for multiple objects, the BOM checks permissions on each object of the return set and removes any objects that the Subject does not have the right to read before returning the set.
• When performing a getObjectForUpdate query, the BOM checks the permissions on the object and does not return the object if the Subject does not have both read and write permission to the object. This throws an ObjectNotFound exception if the query was performed with that option enabled.
• A getObjectsEnumeration query returns an OWBOMEnumeration. The enumeration calls getObjects internally so security is enforced as if you called getObjects.
• A getObjectsAsOIDs query calls getObjectsEnumeration: See above.
• A getObjectsAttributes query calls getObject internally so security is enforced.
• Calling executePassThruQuery may either return a filtered collection of objects or an unfiltered collection of OIDs based on the setting of the returnsObjects boolean of OWBOMPassThruQuery. If only OIDs are returned the filtering occurs when/if you attempt to retrieve object.
You may set permissions on individual BOM objects and objects can be made members of object groups. Permissions assigned to object groups are associated with all objects that are members of that group. An object may be a member of multiple groups.
For performance and ease of administration we recommend you avoid assigning permissions to individual objects and that you do all administration through object groups. The application creating the BOM object is responsible for assigning it to the appropriate object groups.
OLS does not enforce security on the creation of a new object. Applications themselves must control object creation. Until an object has been persisted it may be modified without restriction. While this may seem strange, the creation of new objects usually involves abstract decision logic that is application-dependent. Since the BOM namespace is flat, even context is not available as a default decision factor. An application should use rule security to enforce its decision logic for object creation.
An object retrieved by the BOM may not have its attributes modified without the Subject having write permission to the object. Permission checks are added to the attribute accessors during bean generation. Attributes of newly created objects may be changed without restriction.
Currently, applications must enforce permissions on object deletions. There is no way to enforce delete permission within the BOM without sacrificing backward compatibility. Applications should perform a permission check before deleting an object. This limitation may be overcome as the architecture evolves.