Implementation Guide for Oracle Self-Service E-Billing > Customizing User Management >

Customizing Acegi Security

Oracle Self-Service E-Billing uses the Acegi framework for authentication and authorization. Acegi provides hooks for single sign-on implementation.

DaoAuthenticationProvider from ACEGI is implemented for authentication. DaoAuthenticationProvider leverages a UserDetailsService in order to lookup the username, password and GrantedAuthority[]s. IBillingUserDetailsService extends UserDetailsService and the implementation class implements loadUserByUsername(String userId) method to provide authentication mechanism. This method returns IBillingUserDetails object.

Authorization in Oracle Self-Service E-Billing is based on roles and permissions. Each user is assigned a role. Authorization to access a particular resource is determined by the permissions for a user's role. These permissions are defined in the azpolicy file. Permission is represented by an object called EBillingPermission.

User roles are grouped to form high-level roles, called azPolicyRoles, and permissions are assigned to the azPolicyRoles.

Role mapping is defined in the WEB-INF/classes/azcfg.properties subdirectory, under the application directories for the EAR and WAR files.

The following examples show how to map azPolicyRoles:

• com.edocs.common.security.rolemappers.secrole.ALL_USERS=Admin,User, Payer,Manager, Subscriber,CSR,CSRAdministrator
• com.edocs.common.security.rolemappers.secrole.ADMIN=Admin
• com.edocs.common.security.rolemappers.secrole.MANAGER=Manager
• com.edocs.common.security.rolemappers.secrole.SUBSCRIBER=Subscriber
• com.edocs.common.security.rolemappers.secrole.CSR=CSR
• com.edocs.common.security.rolemappers.secrole.CSR_ADMIN=CSRAdministrator

Once user roles are mapped to azPolicyRoles, define permissions for resources in the azpolicy.xml file, found in the /WEB-INF/classes/azcfg/policy subdirectory, under the application directories for the EAR and WAR files.

Example of sample permission code:

<permission>

<name>perm_company_tab</name> <cpath>com.edocs.common.security.authorize.az.permissions.EBillingPermission</cpath>

<rule>

<name>admin</name> <!--Defines the name of the rule -->

<type>SecurityRole</type> <!-- Type of the rule -->

<values>ADMIN</values> <!-- The role(s) which can access this resource, comma separated. Note it can be an alias defined in azcfg.properties -->

</rule>

</permission>

A permission called perm_company_tab is defined to control the company UI tab. This permission specifies that the company tab is accessible for the azPolicyRole ADMIN. ADMIN is mapped to a user role administrator, making company tab accessible for users whose role is administrator.

After permissions are defined, the code or resources that must be authorized are surrounded by a tag called <authz:authorize>.

This example shows you how to use this tag:

<authz:authorize ifAnyGranted="perm_company_tab">

<li class="sts"><span ><a href="companyProfile.do" title="<bean:message key="global.myAccount.subNavTab3"/>"><bean:message key="global.myAccount.subNavTab3"/></a></span></li>

</authz:authorize>

You can have a list of permissions separated by commas in the ifAnyGanted attribute. If any of the permissions in the list are granted, the body of the tag is written.

The authz:authorize tag can have the following attributes:

• ifAllGranted. All the listed permissions must be granted for the tag to output its body.
• ifAnyGranted. Any of the listed permissions must be granted for the tag to output its body.
• ifNotGranted. None of the listed permissions must be granted for the tag to output its body.