Can #AUTHENTICATED-USERS be removed from FileNet Content Manager

Answer

The #AUTHENTICATED-USERS (or #AU for short) constant represents a logical group within FileNet Content Engine, which contains all users who are able to authenticate to the server. Authentication is controlled by the application servers that host Content Engine and it's clients. In many cases, authentication is controlled via ability to login using username/password credentials against a configured directory server. In other cases, a single sign-on solution (such as IBM Tivoli Access Manager, or CA SiteMinder) controls who can authenticate.

Once a caller has authenticated, their access to Content Engine and it's components is further controlled by permissions on different objects. Some key objects to consider are:

• The Domain object. If a caller does not have at least READ access on the Domain, then they will not be able to access anything within that domain, even though they were able to authenticate.
• The ObjectStore object. If a caller does not have at least CONNECT access to the Object Store, then they will not be able to access anything within that object store. Users are typically granted a set of Object Store rights called USE_OBJECT_STORE, which grants CONNECT, STORE_OBJECTS, MODIFY_OBJECTS, and REMOVE_OBJECTS access. Rights to individual classes / documents / folders are then controlled via more restrictive permissions on those objects, often through use of Roles.
• Classes. Permissions on a class level control who can create an instance of that class (i.e. if you do not have CREATE_INSTANCE permission on a document class, then you cannot create that type of document). DefaultInstance Permissions on a class level control the default permissions that are applied to new instances of that class.
• Folders, Teamspaces, Roles: Applications (like IBM Content Navigator) often set permissions on a folder, teamspace, or role level. These permissions are then inherited down into documents that are filed in folders or sub-folders, from a folder, teamspace or role object.
  

• By default, a P8 domain is created with READ access granted to #AUTHENTICATED-USERS. It is not required to keep this grant in place. If a customer wishes to remove it though, then they must replace it with a similar grant on the domain object, granting READ access to one or more LDAP groups who should have access to object stores within the domain.
• When an Object Store is created, the administrator is asked to provide a list of principals (users and groups) who should have administrative access, and another list who should have general use access. As long as values are provided for both of these lists, then no access to the object store is granted to #AUTHENTICATED-USERS.
• It is a best practice to provide one or more LDAP groups for both of these lists at object store creation time, rather than relying on #AU to control who can access the object store. The list of object store grantees provided at object store creation time are also used to set default permissions on many of the class definitions within the object store.
• Note that if you did not, at object store creation time, provide a value for the list of object store users who can access the object store, then #AU will be granted USE_OBJECT_STORE permission on the object store, and will have similar levels of grants on many class definitions within the object store. In this case, you can effectively narrow access to the object store by replacing the #AU grant on the object store with a grant of USE_OBJECT_STORE to one or more LDAP groups. Although this will not remove the #AU grants to class definitions within the object store, that won't matter, because no one outside of the LDAP groups that are specified on the object store will have any access at all to the object store.
• Note also that if it is necessary to add users or groups to the ObjectStore ACL after object store creation time, then it is recommended to use the ACCE/FEM security wizard for this purpose, as described here: http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSNW2F_5.2.1/com.ibm.p8.security.doc/p8psh025.htm