21 Setting Up Permissions in BRM Applications
Learn how to set up permissions in your Oracle Communications Billing and Revenue Management (BRM) system.
Topics in this document:
See also "Managing Login Names and Passwords".
Setting Up Permissions in BRM Applications
Permissions determine which tasks a user can perform with BRM applications.
A set of permissions defines a role. A role represents a set of actions that a person holding a particular job or position can perform. For more information, see "About Managing Roles".
You can restrict activities in Customer Center, Pricing Center, and other applications by assigning CSRs to a role and setting permissions for that role. For example, you can specify which CSRs can change a password, apply credits, and give refunds.
As part of setting permissions, you do the following:
-
Add permissions to a role.
Note:
For all applications except Customer Center, permission types are not granted by default. CSRs do not have access to the application or feature associated with the permission until permission is explicitly assigned. For Customer Center, some permission types are granted by default. For more information, see Customer Center Help. -
Assign an access level to each permission. For example:
-
You can specify read-only permissions to access critical data such as credit card and pricing information.
-
You can specify read-write access to customer data such as billing address and contact email ID.
-
-
For some permissions, such as giving credits, set a minimum and maximum amount.
When setting the minimum and maximum values for permissions that allow crediting and debiting a customer's account, ensure the value you set is appropriate for all noncurrency balance elements that apply to charge offers any customer might own. For example, if 25 is the maximum credit a CSR can issue to a customer, the CSR cannot credit more than 25 frequent flyer miles or 25 hours of service usage.
You must have proper permissions to add, change, or delete permissions. In most cases, only a person with root access, such as a system administrator, is granted permission to change CSR permissions.
Note:
If your company uses a proprietary application for administering accounts, you can write your own code to set and enforce permissions.
About Permissioning Center
Permissioning Center is a BRM application you can use to enhance security by managing the roles and permissions of BRM client tool users, such as CSRs.
You perform the following tasks using Permissioning Center:
-
Manage roles. You can create, rename, and delete roles; add child roles; and assign CSRs to roles.
-
Manage permissions. You can add and delete permissions.
-
Manage CSRs. You can create CSR accounts, assign CSRs to roles, and unassign CSRs from roles.
CSRs who require access to Permissioning Center must be assigned to a role that includes permissions to use Permissioning Center. You include access permissions to a role in the same way you include any other permissions in Permissioning Center.
About Managing Roles
You use roles to configure permissions for a group of CSRs based on the tasks they must perform. For example, you can create different types of CSRs and assign them to different kinds of roles:
-
Manager CSRs can create new roles, assign CSRs to roles, change permission settings, change credit limits, give refunds, and change account status. A manager can also validate the work that junior CSRs perform (for example, by making sure that new accounts are created correctly and have all the necessary information).
-
Junior CSRs can check customer account balances, check and change billing information, and answer common customer questions.
You can create a role hierarchy in Permissioning Center. To do this, you create child roles and associate them with a parent role.
You organize hierarchical roles according to their permission levels. At each level above the bottom of the hierarchy, the child roles can also be parent roles. A child role inherits all permission settings that are associated with its parent role.
For example, the parent role, CSR, can also have the following child roles:
-
Lead-CSR
-
Junior-CSR
The child roles include all the permissions that belong to the parent role, CSR. In addition, the child roles have all the specific permissions that belong to their particular role, Lead-CSR or Junior-CSR.
About Managing Permissions in Permissioning Center
In Permissioning Center, permissions are based on roles. The role's permissions determine the specific levels of access for the role. Using Permissioning Center, you can create new CSR accounts, assign CSRs to roles, and unassign CSRs from roles. This role-based approach makes it easy to quickly grant or deny permissions to an individual CSR or a group of CSRs with a specific role.
About Permission Types for BRM Applications
You can set permissions for these applications:
- Customer Center: By default, every CSR has the
/customercenter/corrective_bill permission to create corrective bills in
Customer Center, and the Actions menu on the Balance tab will display
the Produce Corrective Bill menu item. To revoke the permission, remove the
/customercenter/corrective_bill permission for the CSR.
You can set some permissions in both Permissioning Center and Customer Center. If you set the same permission in both, the permission you set in Customer Center takes precedence.
For a list of Customer Center permission types, see Customer Center Help.
-
Pricing Center: CSRs are not granted permissions to Pricing Center by default. CSRs do not have access to the application or feature associated with the permission until permission is explicitly assigned.
For a list of Pricing Center permission types, see Table 21-1. All permission types are case sensitive.
Table 21-1 Pricing Center Permission Types
Permission Type Provides Permission to... /appcenter/pricingcenter
Use Pricing Center
/appcenter/provisioningtags
Using Provisioning Tags
/appcenter/ResourceEditor
Use Resource Editor
/appcenter/ZoneMapper
Use Zone Mapper
/loadpricelist/access
Load price list XML files into the BRM database
/pricingcenter/databaseaccess
Take actions that read from and write to the BRM database.
This permission type controls access to the Commit to Portal Database and Import - Real-time Data commands on the File menu. It also controls the type of access you have to pipeline rating functionality in Pricing Center.
If this permission type is set to None, you can only work offline in Pricing Center.
/pricingcenter/filesystemaccess
Take actions that read from and write to files.
This permission type controls access to the following File menu commands:
-
Open
-
Import - Real-time Data
-
Export - Real-time Data
-
Save
-
Save As
-
-
Collections Center: CSRs are not granted permissions to use Collections Center by default. CSRs do not have access to the application or feature associated with the permission until permission is explicitly assigned.
For a list of Collections Center permission types, see Table 21-2. All permission types are case sensitive.
Table 21-2 Collections Center Permission Types
Permission Type Provides Permission to... /collectionapps/collections/updatepayment
Update promise-to-pay payment details in Collections Center.
/collectionapps/collections/newcard
Register a new credit card or direct debit account in Collections Center.
/collectionapps/collections/maskcarddetails
View all digits of a credit card or direct debit account.
Note: If credit card tokenization is enabled, you can view only the last four digits of the credit card. See "Masking Credit Card Numbers by Using Tokens" in BRM Configuring and Collecting Payments.
Managing CSR Passwords
To improve security features and provide access to BRM client applications, the following password policies are included in Permissioning Center:
-
Ability to set password expiry limits. The duration of time that a password is valid until the system prevents a user from logging in or forces the password to be changed.
-
Ability to define temporary passwords. The ability to force CSRs to change their passwords after accessing the application the first time or after a new CSR account has been set up by an administrator.
-
Password content validation. The ability to validate the contents of the password to ensure that certain characters are or are not included, such as numbers.
Setting CSR Account Password Status
The following are the valid password statuses for CSR accounts:
-
Temporary
-
Normal
-
Expires
-
Invalid
You can change a CSR account's password status in Permissioning Center.
To customize how passwords expire, use the PCM_OP_CUST_POL_EXPIRATION_PASSWD opcode. See "Customizing Password Expiration" in BRM Opcode Guide.
Unlocking a Locked CSR Account
To unlock a locked CSR account:
-
At the command prompt, run the BRM_home/bin/pin_unlock_service utility.
A menu appears.
Note:
-
The pin_unlock_service utility needs a configuration (pin.conf) file in the same directory from which you run the utility.
-
Ensure that the account in the pin.conf file is not locked.
-
-
Press 1.
You are prompted to select the type of service: admin_client or pcm_client.
-
Select the service type that is associated with the account you want to unlock:
-
For admin_client, press 1.
-
For pcm_client, press 2.
You are prompted to enter the login ID for the account that you want to unlock.
-
-
Enter the login ID and press the Enter key.
-
Enter a new password for the account.
The password must satisfy the following requirements:
-
It is at least 6 characters in length.
-
It does not exceed 255 characters.
-
It contains a combination of letters and numbers.
-
It is not the same as the login ID.
-
-
Confirm the password to unlock the account.
A message stating that the account has been successfully unlocked appears, followed by a menu.
-
Do one of the following:
-
To unlock another account, press 1.
-
To exit the utility, press 2.
-
Unlocking the Locked root Account
To unlock the locked root account:
-
Go to BRM_home/sys/dm_oracle/data.
-
Connect to your database using SQL*Plus:
sqlplus pin/password@database_name
where database_name is the service name or database alias of the BRM database.
-
Run the following command, which loads the stored procedure:
@create_actlogin_unlockservice_procedures.plb -
Run the following procedure:
exec actlogin_unlockservice.Proc_Unlock_Service('service_type', 'user_name');
where:
-
service_type is the type of service, either /service/admin_client or /service/pcm_client object. BRM stores the permission settings for each role at the root level in the /service/admin_client or /service/pcm_client object in the BRM database.
-
user_name is the root user login name.
The root account is unlocked.
-