Beginning with Enterprise Security 6.0, role mappings are performed implicitly, so you no longer need to explicitly map custom J2EE roles to Enterprise Security roles in the security.properties file. Enterprise Security still checks for role mappings in security.properties before performing implicit role mapping.
For example, if a Portal Interface user attempts to access a portlet that is protected by PortletRole:
Enterprise Security first checks security.properties to see whether an explicit mapping exists for PortletRole. If a role mapping exists for PortletRole, Enterprise Security checks to see whether the Portal Interface user has this role, and permits or denies access to the portlet based on the result.
This duplicates the functionality of earlier versions of Enterprise Security.
If a role mapping for PortletRole is not found in security.properties, Enterprise Security searches the ACDB for a role with the name PortletRole. If there is exactly one role with this name, Enterprise Security checks to see whether the user has this role, and permits or denies access to the portlet accordingly.
If there are zero, two, or more roles in the ACDB with the name PortletRole, a warning is written to security.log that says the system cannot create a default mapping, and access to the portlet is denied.
Implicit role mappings are performed dynamically, so you need not reboot the server after adding a new role.
Implicit role mapping is enabled by default. To disable this feature, edit the security.properties file to set the value of the defaultRolemappingEnabled property to false. If you disable implicit role mapping, you must explicitly map roles in security.properties—see “Mapping J2EE roles to EAServer roles” and “Mapping EAServer roles to Enterprise Security roles”.
If you write a custom authorization delegate that does not use the standard ACDB schema, you must disable implicit role mapping.
