Weblogic 10.3.2 - Visitor entitlements role issue

Question

1)I am upgrading my weblogic portal application from Weblogic 8.1SP4 to Weblogic 10.3.2 version. I found that roles that created under visitor entitlements thru weblogic portal administration portal are not visible to assigned user.For example I created testRole for my application and added user testuser to this user.When I login to my portal application this user should able to see the portal page that related to testRole.But currently this is not working.
To fix the above issue I created one new group under User and groups management and added the above user to that group and added that group to testRole. Now the user is able to see the portal pages
My question is why the user is not able to access the roles when he is not part of any group.Because My portal application have different business users with different entitlement setups which I cannot categorize under groups.
The above functionality is working fine in Weblogic8.1SP4 production environment.
Regards,
Satya

Answer 1

I think the rolemappings in the application are mapped to groups.
The rolemappings are defined through deployment overrides, such as for example, weblogic.xml (which is located in the WEB-INF/lib directory of a WAR file).
An example of such a role mapping is the following:
<weblogic-web-app ...>
     <security-role-assignment>
          <role-name>EMPLOYEE</role-name>
          <principal-name>employees</principal-name>
     </security-role-assignment>
     <security-role-assignment>
          <role-name>MANAGER</role-name>
          <principal-name>managers</principal-name>
     </security-role-assignment>
</weblogic-web-app>The role-name(s) are set in the web.xml of the application, through a security constraint. The principle names are the user or group names
configured in the admin console.
When you edit the weblogic.xml to included a security role assignment and add role-name - principle-name mapping, for example
<security-role-assignment>
     <role-name>visitor</role-name>
     <principal-name>testuser</principal-name>
</security-role-assignment>now the testuser has visitor rights.