This chapter explains how to set up permissions and passwords for your Oracle Communications Billing and Revenue Management (BRM) system.
Before you read this chapter, you should be familiar with how BRM works. See "BRM System Architecture" in BRM Concepts.
For information on authenticating and authorizing customers, see "Managing Customer Authentication" in BRM Managing Customers.
You can use the usual database and operating-system security measures for the BRM system. For example, you can set up read/write/execute permissions and group permissions on files and programs.
As shipped, BRM uses encryption only for passwords. However, you can encrypt any string field. For more information, see "About Encrypting Information" in BRM Developer's Guide.
The following principles are fundamental to using any application securely:
Keep software up to date. This includes the latest product release and any patches that apply to it.
Monitor system activity. Establish who should access which system components, and how often, and monitor those components.
Install software securely. For example, use firewalls, secure protocols such as SSL, and secure passwords.
Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible.
See the "Critical Patch Updates and Security Alerts" article on the Oracle Technology web site:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
When planning your BRM implementation, consider the following:
Which resources must be protected?
You must protect customer data, such as credit-card numbers.
You must protect internal data, such as proprietary source code.
You must protect system components from being disabled by external attacks or intentional system overloads.
Who are you protecting data from?
For example, you must protect your subscribers' data from other subscribers, but someone in your organization might need to access that data to manage it. You can analyze your workflows to determine who needs access to the data; for example, a system administrator might be able to manage your system components without accessing the system data.
What will happen if protections on strategic resources fail?
In some cases, a fault in your security scheme is nothing more than an inconvenience. In other cases, a fault might cause great damage to you or your customers. Understanding the security ramifications of each resource will help you protect it properly.
BRM uses other Oracle products, such as Oracle Database and Oracle WebLogic Server.
For more information, see the following documents:
Oracle Database Security Guide
Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server
Oracle WebLogic Server documentation
Oracle documentation is available from the Oracle Technology Network web site:
By default, the BRM installer stores database and account passwords in encrypted form in the Infranet.properties and pin.conf configuration files. The BRM applications can automatically decrypt the passwords when retrieving them from the configuration files.
By default, the passwords in the configuration files are encrypted in the Advanced Encryption Standard (AES) format. For more information, see "About AES Encryption" in BRM Developer's Guide.
Note:
To encrypt passwords for client applications or optional managers that are not part of base BRM, or are associated with customizations, use the pin_crypt_app utility. For details, see "About Encrypting Passwords" and "Encrypting Passwords Manually" in BRM Developer's Guide.Passwords for the Connection Manager (CM) must adhere to the following rules:
Contain a minimum of eight characters
Include at least one numeric character, one uppercase character, and one special character
Differ from the previous four passwords
Not include any part of the user ID
The Data Manager (DM) configuration file (BRM_home/sys/dm_oracle/pin.conf; where BRM_home is the directory in which BRM is installed) specifies the user name and password for logging in to the BRM database. This is the user name and password you specified when you installed and configured the database. By default, the user name is pin and the password is pin.
Note:
You can automatically encrypt passwords for all BRM components (including dm_oracle) simultaneously by running the encryptpassword.pl script. For more information, see "About the encryptpassword.pl Script" in BRM Developer's Guide.To access the BRM database, a client application must provide the following:
An account name
The password for that account
The service
The database number of the BRM database
With that information, the CM queries the database. If the information is authenticated, the CM grants the application access to the database.
When you install BRM, the system creates a single user account, called root and identified by the password password, with general permission to the BRM system. This account includes two services: admin_client and pcm_client.
BRM client applications log in to the admin_client service.
Other BRM utilities and programs, such as optional service integration components, log in to the pcm_client service.
The default login name and password provided with the system are root.0.0.0.n (where n is your database number) and password.
Caution:
You must change the password after installing BRM to prevent unauthorized access to BRM.When you set up a production BRM system, you create additional accounts—for example, one for each of your customer service representatives (CSRs)—and associate one or more services with each account. You give each account a password and grant certain privileges to the account. For example, you might want to allow only some of your CSRs to handle payment disputes.
You also must provide an account for any extended applications you use with BRM.
Note:
You cannot change the payment method of the root account or make it a parent or child account.By default, the CM is configured to require a service, a login name, and a password. This provides secure access to BRM.
If only secure applications will connect to your CM, you can speed up the login process by configuring the CM to verify only the service but not require a login name or password.
To configure the CM to verify application logins with the service only:
Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
Change the cm_login_module entry from cm_login_pw001.dll to cm_login_null.dll:
- cm cm_login_module cm_login_null.dll
Stop and restart the CM. See "Starting and Stopping the BRM System".
Configure the applications that connect with this CM to provide only service information at log in. In the configuration file for each application, set login_type to 0, and ensure a valid service is listed for userid.
Tip:
CM Proxy provides another way of connecting to BRM without using a login name and password. See "Using CM Proxy to Allow Unauthenticated Log On".To configure the maximum number of invalid login attempts:
Run the following command:
pin_bus_params -r BusParamsActivity bus_params_act.xml
This command creates the XML file named bus_params_act.xml.out in your working directory. If you do not want this file in your working directory, specify the full path as part of the file name.
Search the XML file for the following line:
<MaxLoginAttempts>5</MaxLoginAttempts>
Set the value (the default is 5) to the maximum number of login attempts.
Save the file as bus_params_act.xml.
Run the following command, which loads the change into the /config/business_params object:
pin_bus_params bus_params_act.xml
Run this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.
Read the object with the testnap utility or Object Browser to verify that all fields are correct.
Stop and restart the CM. See "Starting and Stopping the BRM System".
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb".
BRM client applications provide login information in various ways:
BRM Java-based applications, including Pricing Center, Customer Center, and Configuration Center, ask the user for port numbers and database names when the application starts.
Payment Tool provides port numbers and database names in its .ini file.
BRM optional service integration components, such as RADIUS Manager, provide all login information from the configuration file for that application.
To change the default login information for client applications, edit the .ini or configuration file or use the login dialog box.
To change most connection information for Java-based client applications, use the login dialog box, which appears when you start the application. The application uses this default information for subsequent sessions.
The BRM Java-based client applications' passwords are located in their Infranet.properties files as encrypted text. To change and encrypt new passwords for an application, log in to the server hosting the application and use the pin_crypt_app utility to encrypt the new password manually. For details, see "About Encrypting Passwords" and "Encrypting Passwords Manually" in BRM Developer's Guide.
To change the default login information for Payment Tool:
Open the C:\Windows\PaymentTool.ini file.
Edit the login entries.
Save and close the file.
To change the default login information for optional service integration components:
Open the configuration file for the application, which you can find in the directory for that application.
Follow the guidelines in the configuration file to provide information for these configuration entries:
userid
login_type
login_name
login_pw
Set up accounts for your company's CSRs so they can create and manage customer accounts.
Before creating CSR accounts, create and load a CSR plan, which defines the services available to CSRs. You do this in Pricing Center. See "Creating CSR Plans" in BRM Setting Up Pricing and Rating.
You can create CSR accounts in either Customer Center or Permissioning Center. After a CSR account exists, you can make changes to it only in Customer Center.
To create CSR accounts:
In Customer Center: See "Creating a CSR Account" in the Customer Center Help.
In Permissioning Center: In People view, choose Actions - Create New Person. For more information, see the Permissioning Center Help. For information on password settings for CSR accounts, see "Managing CSR Passwords".
To change the login information for an account, use Customer Center. You can log in to the account you want to change, or you can log in to the BRM root account or another account with permission to change the password. You can change the login name and password for each service associated with the account. See the Customer Center Help for more information.
Important:
The BRM root account comes with the default password of password. To prevent unauthorized access to your system, change this password for both services associated with the root account.The log information includes the type of activity, the date and time the CSR performed the activity, and the IP address of the client computer. This data is stored in the /user_activity storable class.
Note:
To log CSR activities, session-event logging must be turned on. Session-event logging is on when the CM pin.conf file's login_audit entry is set to 1 or commented out. See "Turning Off Session-Event Logging" for more information.If you are using an external customer relationship management (CRM) application to connect to BRM, BRM also logs the external CSR user ID along with the user activity in the /user_activity storable class. You can use the external CSR ID during auditing to trace any actions performed by the external CSR in BRM. If the external CRM application does not send the external CSR user ID to BRM, BRM logs NULL values in the /user_activity storable class.
You can log CSR activities only if you have included them in the pin_notify file. For more information on using the pin_notify file for event notifications, see "Merging Event Notification Lists" in BRM Developer's Guide. Use the load_pin_notify utility to load the events specified in the pin_notify file into the BRM database. See BRM Managing Customers.
Note:
To generate a report displaying the log data, you must write your own query and GUI custom code.You can log the following CSR activities:
Account creation
Account hierarchy changes
Bill adjustments
Bill Now operations
Changes to billing day of month
Changes to billing frequency
Changes to credit card information
Creation of charge, discount, monitor, and profile sharing groups
Creation of deferred action schedules
Credit limit changes
Deletion of charge, discount, monitor, and profile sharing groups
Disputes
Event adjustments
Item adjustments
Modifications to charge, discount, monitor, and profile sharing groups
Payments
Password change
Product cancellation
Product modification
Product purchase
Refunds
Service login name change
Settlements
Top-ups
Write-offs
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. For information on the types of permissions that you can set, see "Permission Types".
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 the 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 resources that apply to products 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 can set up permissions using both Permissioning Center and Customer Center. However, you must have proper permissions to add, change, or delete permissions. Usually, only a person with root access, such as a system administrator, is granted permission to change CSR permissions. For more information, see "About Managing Permissions in Permissioning Center".
Note:
If your company uses a proprietary application for administering accounts, you can write your own code to set and enforce permissions.You can also restrict access to accounts in a specific brand. To do this, use Access Privileges in Configuration Center. See "About Granting Access to Brands" in BRM Managing Customers.
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. For more information, see "About Managing Roles".
Manage permissions. You can add and delete permissions. For more information, see "About Managing Permissions in Permissioning Center".
Manage CSRs. You can create CSR accounts, assign CSRs to roles, and unassign CSRs from roles.
Note:
You can create CSRs by using Customer Center or Permissioning Center. You assign individual permissions by using Customer Center, and you assign role-based permissions to CSRs by using Permissioning Center.You can view the permissions included in a role and the CSRs assigned to a role by using the Role view and People view in Permissioning Center.
Using Permissioning Center, you can grant or deny access to entire applications, such as Pricing Center or Customer Center, or to individual tabs and fields within Customer Center. This enables you to assign CSRs to roles that correspond to their job functions.
For information on how to create roles and permissions and how to assign CSR accounts to roles, see the Permissioning Center Help.
The installation procedure for Permissioning Center is similar to the installation of the other client applications in BRM. See "Installing BRM Client Applications on Windows" in BRM Installation Guide.
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.
A person who has BRM root privileges has full access permissions to create roles and to add permissions to or delete permissions from a role in Permissioning Center, Customer Center, or Pricing Center.
A brand manager has default access to Permissioning Center. For other client applications, like Customer Center and Pricing Center, brand managers must assign roles that contain permissions for accessing the other client applications to themselves.
Note:
After installing Permissioning Center, only the BRM root login name has permissions to use Permissioning Center.For more information on how to manage and include permissions in a role, see the Permissioning Center Help.
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.
For example, CSRs A and B can be assigned to the role Manager, and CSRs C and D can be assigned to the role Lead-CSR, where:
CSRs A and B have read-write access for customer credit card information.
CSRs C and D have read-only permissions for customer credit card information.
You can also create roles with higher levels of permissions. For example, you can create roles that include permissions to create and manage roles using Permissioning Center.
You can include specific permissions in a role to access one or more client applications. In addition, a CSR can be assigned to multiple roles. For example, a CSR can be assigned to a Manager role in Permissioning Center and to a Junior-CSR role in Pricing Center.
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.
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. For more information, see "About Permissioning Center".
In Customer Center, you can provide only one permission at a time to a CSR. Roles cannot be created in Customer Center.
Important:
The permissions set in Customer Center overwrite those set in Permissioning Center.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.
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.
Note:
By default, the password status for a brand manager is set to Normal, and the status for a CSR account is set to Temporary.When a CSR logs in to a BRM application, the system checks for the password status and takes the following actions:
If the CSR logs in to the application for the first time or if the password is set to Temporary, the Change Password screen is displayed. The CSR is required to change the password before using the application. After the CSR changes the password, the password status is changed from Temporary to Normal.
If the password status is set to Normal, the CSR password never expires.
If the password status is set to Expires, Customer Center invalidates the CSR password after a specified number of days (90 days by default). When a CSR tries to log in after the expiration time period, the CSR is required to change the password. After the CSR changes the password, the password status remains as Expires, and the new password expires after the specified number of days.
For information about setting the default password expiration, see "Setting the Default Password Expiry Duration".
If the password status is set to Invalid, access to the application is denied.
After you log in to a BRM client application and leave it idle for a specified interval, the session expires automatically. To reconnect to the session, you are prompted to enter your password. However, if you have specified the password in the Infranet.properties file, the application automatically reads the password from the Infranet.properties file and automatically reconnects.
Note:
The default interval for automatic logout is set to 0 minutes, which implies that this feature is disabled by default. However, this might be different in your BRM system depending on the number specified in the cm_timeout entry in the CM's pin.conf file. For more information on cm_timeout, see "Setting the CM Time Interval between Opcode Requests".To access the application after an automatic logout:
In the Confirm Password dialog box, enter the password.
Click OK.
Note:
BRM client applications use multiple connections. Because the interval for automatic logout is different for each connection, you must perform the above steps once for each connection. Also, if you do not access a window or dialog box for a specified interval, the session expires automatically.After you log in to a BRM client application, you can change your existing password. After you change the password, you can log in to any BRM application with your new password.
Note:
You cannot access the application with a temporary or expired password. You are required to change the password to proceed.
The number of attempts at entering a password is limited. If you exceed this limit, your account is locked and only a system administrator can unlock the account.
The default number of attempts is five, but it might be different in your BRM system depending on the value of the <MaxLoginAttempts> element in the bus_params_act.xml file. See "Configuring the Maximum Number of Invalid Login Attempts".
To change the password:
From the File menu, select Change Password.
The Change Password dialog box appears.
In the Enter current password field, enter your current password.
In the Enter new password field, enter your new password.
In the Re-enter new password field, enter the same password to confirm.
Click OK.
To unlock a locked CSR account:
At the command prompt, run the BRM_home/bin/pin_unlock_service utility.
A menu appears.
Important:
The pin_unlock_service utility needs a configuration (pin.conf) file in the same directory from which you run the utility. See "Creating Configuration Files for BRM Utilities".
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 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.
To change the default password expiry duration:
Open the BRM_home/sys/cm/pin.conf file.
Change the value of the passwd_age entry:
- cm passwd_age 90
The default is 90.
Stop and restart the CM. See "Starting and Stopping the BRM System".
To unlock the locked root account:
Go to BRM_home/sys/dm_oracle/data/.
Connect to your database using SQL*Plus:
sqlplus pin/pin@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 admin_client or pcm_client object. BRM stores the permission settings for each role at the root or brand 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.
You use Permissioning Center to define permission settings for each role at the root or brand level in the /service/admin_client object in the BRM database.
When you assign a CSR account to a role, the account includes all the permissions that are assigned to the role.
Important:
A CSR account can be assigned to only one role per application.The PIN_FLD_ROLE field in the account contains the roles assigned to the CSR account.
You can set permissions for the following applications:
Collections Center. See "Collections Center Permission Types".
Customer Center. See the Customer Center Help.
Pricing Center. See "Pricing Center Permission Types".
Suspense Management Center. See "Suspense Management Center Permission Types".
Other client applications. See "Other Client Application Permission Types".
Note:
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 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.
Permission types are case sensitive.
The Min value does not apply to any of the Suspense Management Center permission types.
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.
Table 5-1 shows the permissions you can set for Collections Center.
Table 5-1 Collections Center Permission Types
| Permission Type | Provides Permission To . . . |
|---|---|
|
/appcenter/collectioncenter |
Use Collections Center. |
|
/accounttool/collections/agent |
Perform the role of collections agent, who carries out collections tasks without any supervisory responsibilities. |
|
/accounttool/collections/manager |
Perform the role of collections manager, who supervises collections agents. |
|
/collectionapps/collections/actionhistory |
View the history of individual tasks. |
|
/collectionapps/collections/assign |
Assign bill units to collections agents. |
|
/collectionapps/collections/changestatus |
Change the status of a task. |
|
/collectionapps/collections/chargeCC |
Receive credit card payments. |
|
/collectionapps/collections/exempt |
Exempt bill units from collections. |
|
/collectionapps/collections/insert |
Insert an additional task into a bill unit scenario. |
|
/collectionapps/collections/maskcarddetails |
View all of the credit card numbers or all of the direct debit account numbers. Note: If credit card tokenization is enabled, you can view only the last 4 digits of the credit card number. For more information about credit card tokenization, see "About Credit Card Tokenization" in BRM Configuring and Collecting Payments. |
|
/collectionapps/collections/promisetopay |
Set the promise-to-pay feature for any bill unit. |
|
/collectionapps/collections/removeexempt |
Remove bill units from exemption. |
|
/collectionapps/collections/reschedule |
Reschedule tasks. |
|
/collectionapps/collections/updatepayment |
Update the payment details for a bill unit. |
|
/collectioncenter/newcard |
Register new cards or new accounts. |
Table 5-2 shows the permissions you can set for Pricing Center.
Table 5-2 Pricing Center Permission Types
| Permission Type | Provides Permission To . . . |
|---|---|
|
/appcenter/pricingcenter |
Use Pricing Center. |
|
/appcenter/provisioningtags |
Use 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 |
Table 5-3 shows the permissions you can set for Suspense Management Center.
Table 5-3 Suspense Management Center Permission Types
| Permission Type | Provides Permission To . . . | Max Value Applies |
|---|---|---|
|
/appcenter/suspensemgt |
Use Suspense Management Center. |
No |
|
/appcenter/suspensemgt/archive_and_purge |
Archive and purge call records, save the records to an archive file, and remove them from the BRM database. |
Yes |
|
/appcenter/suspensemgt/batch |
Search batches. |
Yes |
|
/appcenter/suspensemgt/batch_writeoff |
Write off batches. |
Yes |
|
/appcenter/suspensemgt/batch_purge |
Remove batches from the database. |
Yes |
|
/appcenter/suspensemgt/batch_resubmit |
Resubmit batches and send them back through a pipeline for rating. |
Yes |
|
/appcenter/suspensemgt/bulkedit |
Edit a large number of suspended call records in one database operation. |
Yes |
|
/appcenter/suspensemgt/bulkpurge |
Delete a large number of suspended call records in one database operation. |
Yes |
|
/appcenter/suspensemgt/bulkrecycle |
Recycle a large number of suspended call records in one database operation. |
Yes |
|
/appcenter/suspensemgt/bulkwriteoff |
Write off a large number of suspended call records in one database operation. |
Yes |
|
/appcenter/suspensemgt/edit |
Edit suspended call records. |
Yes |
|
/appcenter/suspensemgt/purge |
Purge call records from the BRM database. |
Yes |
|
/appcenter/suspensemgt/records |
Search records. |
Yes |
|
/appcenter/suspensemgt/recycle |
Recycle suspended call records and send them back through a pipeline for rating. |
Yes |
|
/appcenter/suspensemgt/restore |
Restore call records from an archive file. |
No |
|
/appcenter/suspensemgt/undo_edit |
Undo edits to suspended call records. |
No |
|
/appcenter/suspensemgt/writeoff |
Write off suspended call records. |
Yes |
Table 5-4 shows the permissions for accessing client applications. To set up permission for accessing a client application, choose that application's name from the Application list and enter the permission type.
Table 5-4 Other Client Application Permission Types
| Permission Type | Provides Permission To . . . |
|---|---|
|
/appcenter/collectionconfig |
Use Collections Config. |
|
/appcenter/IPAdmin |
Use IP Address Administration Center. |
|
/appcenter/paymentcenter |
Use Payment Center. |
|
/appcenter/racenter |
Use Revenue Assurance. |
|
/paymenttool/access |
Use Payment Tool. |
The permission levels included in a role determine the access level of the CSR. The permission levels are listed in Table 5-5:
BRM systems that use branded service management to host multiple brands of service use privileges to keep each brand's customer accounts and price lists separate. The root account has access to all brands. The Brand Manager accounts that you define when creating a brand have access to all data in that brand.
Other users, such as CSRs, get access to brands through access groups. Each access group gives member users access to a single brand or to a single subbrand or account group within a brand.
You create access groups in the Access Privileges application in Configuration Center.
For more information, see "About Granting Access to Brands" in BRM Managing Customers and the Access Privileges Help.
BRM stores account passwords (for /service/admin_client and /service/pcm_client) in encrypted form in the database.
Important:
If a BRM user forgets a password, you must provide a new one; you cannot retrieve the old one.You can change the encryption algorithm, which is AES by default, to another algorithm. To do this, modify the fm_cust_pol_encrypt_passwd.c policy module in BRM_home/source/sys/fm_cust_pol. See "Adding and Modifying Policy Facilities Modules" in BRM Developer's Guide for more information.
BRM developers can also encrypt other string fields. If your BRM system uses a custom encryption method, the encryption values in the DM configuration file (BRM_home/sys/dm_oracle/pin.conf) should be updated. For instructions, see "Encrypting Fields" in BRM Developer's Guide.
IP passwords (for /service/ip) are clear text; this is a requirement of Challenge Handshake Authentication Protocol (CHAP). However, the password is never sent to the NAS (terminal server), either in encrypted or clear-text form because CHAP encrypts a random-number challenge token based on the customer's password.
Secure connections between applications can be obtained by using protocols such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). The term SSL is often used to refer to either of these protocols or a combination of the two (SSL/TLS). BRM supports SSL/TLS to provide secure communication between:
CMs and DMs
CMs and External Modules (EMs)
Note:
Currently, secure communication using SSL/TLS is not supported between CMs and NET_EM.PCM clients and the CM
PCM clients and the CM when using Connection Manager Master Processes (CMMPs)
BRM server and BRM database
Note:
BRM no longer supports Secure Sockets Layer 3.0. For BRM, Oracle recommends that you use TLS protocol for secure communication. In the BRM 7.5 documentation, secure communications is referred to by the generic term SSL/TLS.To enable secure communication between BRM components:
Create an Oracle wallet. See "Working with SSL/TLS Certificates and Oracle Wallets".
Enable SSL/TLS in the CM. See "Enabling SSL/TLS in Connection Managers".
Enable SSL/TLS in the DM. See "Enabling SSL/TLS in Data Managers".
Enable SSL/TLS in your C PCM clients. See "Enabling SSL/TLS for C and C++ PCM Clients".
Enable SSL/TLS in your Java PCM clients. See "Enabling SSL/TLS for Java PCM Clients".
Enable SSL/TLS in your Java server process. See "Enabling SSL/TLS for Java Server Processes".
Enable SSL/TLS in CMMP. See "Enabling SSL/TLS in Connection Manager Master Processes".
Enable SSL/TLS in BRM JCA Resource Adapter. See the description of the JavaPcmSSL, SSLWalletLocation, and SslCipherSuites entries in BRM JCA Resource Adapter.
The Oracle wallet is a password-protected container that stores SSL/TLS authentication and signature credentials, such as private keys, and certificates. You must create an Oracle wallet containing a trusted server certificate for the CM. You can create either an Oracle wallet with SSL/TLS authentication and credentials for each PCM client or one Oracle wallet whose SSL/TLS authentication and credentials are shared by a group of PCM clients.
BRM provides sample server and client Oracle wallets and trusted certificates that are compatible with the default cipher suite, SSL_RSA_WITH_AES_128_CBC_SHA. The sample server and client Oracle wallets and trusted certificates can be used for testing purposes. Set your CM and PCM clients to the following directories:
To use the server Oracle wallets and trusted certificate samples, set the CM to BRM_home/wallet/server. The server Oracle wallet contains the trusted server certificate and a certificate authority (CA) certificate.
To use the client Oracle wallet and trusted certificate samples, set the PCM client to BRM_home/wallet/client. The client Oracle wallet contains the trusted certificate and a certificate authority (CA) certificate.
Note:
By default, a sample Oracle wallet named cwallet.sso is installed for Java PCM clients. For more information, see "Enabling SSL/TLS for Java PCM Clients".Note:
The password to make changes to the server and client Oracle wallet samples is Welcome1.SSL/TLS uses signed certificates to check and verify two applications on a network. In BRM, trusted certificates are used to check and verify the identification of the CM and the PCM client. Each PCM client and CM Oracle wallet must contain a trusted certificate and a CA certificate. The CA certificate signs a certificate to make it trusted and checks certificates from other applications to make sure that they come from a trusted CA source.
A sample CA certificate can be found in BRM_home/wallet/root directory. You can use the sample CA certificate, set up your own CA certificate, or use a CA certificate from a third party.
Before you enable SSL/TLS in BRM, an Oracle wallet containing a trusted server certificate must be created for each CM, DM, and EM.
To create an Oracle wallet and server certificate:
Go to the BRM_home/ThirdPartyApps directory.
Run the source command on the source.me file:
For Bash shell:
source source.me.sh
For C shell:
source source.me.csh
Run the following command:
create_svr_wallet_cert -dn "CN=host_name"
where host_name is the server host name.
An Oracle wallet and trusted server certificate are created in the BRM_home/wallet/server directory. The create_svr_wallet_cert script uses the sample CA certificate to sign the server certificate. When asked for the password to make changes to the server Oracle wallet, use Welcome1.
(Optional) To enable two-way server and client authentication between the CM and the PCM client, create a trusted client certificate using the orapki utility and the sample CA certificate, and enable two-way server and client authentication for the CM.
The sample CA certificate is in the BRM_home/wallet/root directory. For more information about the orapki utility, see Oracle Database Advanced Security Administrator's Guide.
For example:
Go to BRM_home/bin.
Create a certificate request by running the following command:
orapki wallet add -wallet BRM_home/wallet/client -keysize 1024 -dn cn=test_client,dc=us,dc=oracle,dc=com -pwd Welcome1
Export the certificate request to a file by running the following command:
orapki wallet export -wallet BRM_home/wallet/client -dn cn=test_client,dc=us,dc=oracle,dc=com -request BRM_home/wallet/client/ccreq.txt -pwd Welcome1
where the -request parameter specifies the file name.
Create a trusted certificate by running the following command:
orapki cert create -wallet BRM_home/wallet/root -request BRM_home/wallet/client/ccreq.txt -cert BRM_home/wallet/client/ccert.txt -validity 3650 -pwd Welcome1
where the -validity parameter specifies the number of days that the certificate is valid.
Add the client certificate into the client wallet by running the following command:
orapki wallet add -wallet BRM_home/wallet/client -user_cert -cert BRM_home/wallet/client/ccert.txt -pwd Welcome1
Enable two-way server and client authentication for the CM. For more information on how to enable two-way authentication between server and client, see "Enabling SSL/TLS in Connection Managers".
You can use the orapki utility to create Oracle wallets and certificates and to import certificates into Oracle wallets. The orapki utility is in the BRM_home/bin directory.
For more information about the orapki utility, see Oracle Database Advanced Security Administrator's Guide.
To create an Oracle wallet by using the orapki utility:
Go to the BRM_home/bin directory.
Run the following command:
orapki wallet create -wallet wallet_location -auto_login -pwd password
where:
wallet_location is the directory in which the Oracle wallet is to be created.
password is the password used to make changes to the Oracle wallet.
Passwords for the orapki utility must adhere to the following rules:
Contain a minimum of eight characters
Include at least one numeric character, one uppercase character, and one special character
Differ from the previous four passwords
Not include any part of the user ID
Caution:
For security reasons, Oracle recommends that you do not specify the password at the command line. Instead, enter the password when prompted to do so.All SSL/TLS Oracle wallets must have the auto_login parameter enabled. The auto_login parameter opens the wallet without the need for a password. If you wish to make changes to the wallet, a password must be provided.
Cipher suites contain authentication, encryption, and MAC algorithms, which are used to protect information during key exchange, bulk encryption, and message authentication. BRM lists the cipher suites it supports, in order of preference.
During the SSL/TLS handshake between the PCM client and the CM, the PCM client sends the supported cipher suite list to the CM. The CM selects a cipher suite and returns its selection to the PCM client.
By default, the following BRM-supported cipher suites are set to use SSL/TLS for C and C++ PCM clients:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA256
SSL_RSA_WITH_AES_256_CBC_SHA256
SSL_RSA_WITH_AES_128_GCM_SHA256
SSL_RSA_WITH_AES_256_GCM_SHA384
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
By default, the following BRM-supported cipher suites are set to use SSL/TLS for Java PCM clients:
TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
By default, SSL/TLS is disabled in the CMs.
Note:
If you have multiple CMs on the same machine or if you are creating a new CM, each CM needs its own Oracle wallet. See "Creating an Oracle Wallet and a Server Certificate".To enable SSL/TLS in a CM:
Open the BRM_home/sys/cm/pin.conf file in a text editor.
Add the following entry:
- cm enable_ssl 1
(Optional) To enable two-way server and client authentication between the CM and the PCM client, add the following entry:
- cm ssl_auth 2-way
For information on how to create a trusted server certificate to use when enabling two-way authentication, see "Creating an Oracle Wallet and a Server Certificate".
(Optional) If your server Oracle wallet is not in the default directory (BRM_home/wallet/server), add the following entry:
- cm wallet wallet_location
where wallet_location is the full path to the directory in which your server Oracle wallet resides.
(Optional) To add cipher suites, do one of the following:
To add one cipher suite, add the following entry:
- cm cipher cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- cm cipher SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- cm cipher SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
Stop and restart the CM. See "Starting and Stopping the BRM System".
By default, SSL/TLS is disabled in the DMs.
Note:
If you have multiple DMs on the same machine or if you are creating a new DM, each DM needs its own Oracle wallet. See "Creating an Oracle Wallet and a Server Certificate".To enable SSL/TLS in a DM:
Open the BRM_home/sys/data_manager/pin.conf file in a text editor, where data_manager is the folder for the DM you want to enable secure communication for.
Add the following entry:
- dm enable_ssl 1
(Optional) To enable two-way authentication between the CM and the DM, add the following entry:
- dm ssl_auth 2-way
For information on how to create a trusted server certificate to use when enabling two-way authentication, see "Creating an Oracle Wallet and a Server Certificate".
(Optional) If your server Oracle wallet is not in the default directory (BRM_home/wallet/server), add the following entry:
- dm wallet wallet_location
where wallet_location is the full path to the directory in which your server Oracle wallet resides.
(Optional) To add cipher suites, do one of the following:
To add one cipher suite, add the following entry:
- dm cipher cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- dm cipher SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- dm cipher SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
Stop and restart the DM. See "Starting and Stopping the BRM System".
By default, the ability to use SSL/TLS with C and C++ PCM clients is disabled.
To enable SSL/TLS for C and C++ PCM clients:
Open the pin.conf file of the PCM client application in a text editor.
Add the following entry:
- nap enable_ssl 1
(Optional) To enable two-way server and client authentication between the CM and C and C++ PCM clients, add the following entry:
- nap ssl_auth 2-way
(Optional) If your client Oracle wallet is not in the default directory, add the following entry:
- nap wallet wallet_location
where wallet_location is the full path to the directory in which your client Oracle wallet resides.
(Optional) To add cipher suites for C and C++ PCM clients, do one of the following:
To add one cipher suite, add the following entry:
- nap cipher cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- nap cipher SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- nap cipher SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
Stop and restart the CM. For more information, see "Starting and Stopping the BRM System".
By default, the ability to use SSL/TLS with Java PCM clients is disabled. When you install a Java client application, a sample Oracle wallet named cwallet.sso is installed in the directory in which you install the Java client application.
Important:
Only administrators with write permissions can make changes to the Infranet.properties file.To enable SSL/TLS for Java PCM clients, do the following for each Java PCM client:
Open the Java Infranet.properties file in a text editor.
Table 5-6 lists the default location of the Infranet.properties file for each Java PCM client.
Table 5-6 BRM Client Infranet.properties File Default Locations
| Client Name | Directory Path |
|---|---|
|
Business Configuration Center |
Windows XP — C:\Program Files\Common Files\Portal Software\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Common Files\Portal Software\Infranet.properties |
|
Revenue Assurance Center |
Windows XP — C:\Program Files\Portal Software\RevenueAssuranceCtr\RevenueAssuranceCenter\lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\RevenueAssuranceCtr\RevenueAssuranceCenter\lib\Infranet.properties |
|
Collections Center |
Windows XP — C:\Program Files\Portal Software\Collections Center\Lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\Collections Center\Lib\Infranet.properties |
|
Collections Configuration |
Windows XP — C:\Program Files\Portal Software\CollectionsConfiguration\Lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\CollectionsConfiguration\Lib\Infranet.properties |
|
Customer Center |
Windows XP — C:\Program Files\Portal Software\CustomerCenter\lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\CustomerCenter\lib\Infranet.properties |
|
Developer Center |
Windows XP — C:\Program Files\Common Files\Portal Software\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Common Files\Portal Software\Infranet.properties |
|
IP Address Administration Center |
Windows XP — C:\Program Files\Portal Software\IPAddressAdministrationCenter\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\IPAddressAdministrationCenter\Infranet.properties |
|
Number Administration Center |
Windows XP — C:\Program Files\Common Files\Portal Software\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Common Files\Portal Software\Infranet.properties |
|
Permissioning Center |
Windows XP — C:\Program Files\Portal Software\PermissioningCenter\lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\PermissioningCenter\lib\Infranet.properties |
|
Pricing Center |
Windows XP — C:\Program Files\Portal Software\PricingCenter\lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\PricingCenter\lib\Infranet.properties |
|
SIM Administration Center |
Windows XP — C:\Program Files\Common Files\Portal Software\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Common Files\Portal Software\Infranet.properties |
|
Suspense Management Center |
Windows XP — C:\Program Files\Portal Software\SuspenseManagementCenter\lib\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Portal Software\SuspenseManagementCenter\lib\Infranet.properties |
|
Voucher Administration Center |
Windows XP — C:\Program Files\Common Files\Portal Software\Infranet.properties Windows 7 and Windows 8.1 — C:\Program Files (x86)\Common Files\Portal Software\Infranet.properties |
Search for the following line:
- infranet.pcp.ssl.enabled=false
Change false to true.
- infranet.pcp.ssl.enabled=true
(Optional) To enable two-way server and client authentication between the CM and Java PCM clients, add the following entry:
- infranet.pcp.ssl.client_auth = true
(Optional) If the Java PCM client Oracle wallet is not in the default location, add the following entry:
- infranet.pcp.ssl.wallet.location=wallet_location/wallet
where wallet_location is the full path to the directory in which your Java PCM client Oracle wallet resides.
(Optional) If your Java PCM client Oracle wallet name is different from the sample Java PCM client Oracle wallet name, add the following entry:
- infranet.pcp.ssl.wallet.filename=wallet_name.sso
where wallet_name is the name of your Java PCM client Oracle wallet.
(Optional) Change the timeout setting for the SSL/TLS handshake between the CM and Java PCM clients by setting the infranet.pcp.ssl.handshake.timeout entry to the appropriate number of milliseconds:
- infranet.pcp.ssl.handshake.timeout=timeout_in_milliseconds
The default is 30000.
(Optional) To add cipher suites for Java PCM clients, do one of the following:
To add one cipher suite, specify the name of the cipher suite in the following entry:
- infranet.pcp.ssl.handshake.ciphersuites=cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- infranet.pcp.ssl.handshake.ciphersuites=SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- infranet.pcp.ssl.handshake.ciphersuites=TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses TLS_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
Verify that the BRM_home/jars/oraclepki.jar, BRM_home/jars/osdt_cert.jar, BRM_home/jars/osdt_core.jar, BRM_home/jars/httpclient-4.4.jar, and BRM_home/jars/commons-logging-1.2.jar files are in the CLASSPATH.
To enable SSL for Customer Center Web Start deployment:
Package the SSL wallet files into a JAR file; for example, wallet.jar.
Copy the JAR file to the Customer_Center_Home/3plibs directory, where Customer_Center_Home is the directory in which you installed Customer Center on your Web server.
Create a Java Network Launch Protocol (JNLP) file; for example, brmwallet.jnlp, and copy it to the Customer_Center_Home directory in which the CustomerCenter_en.jnlp is located.
The following is the sample JNLP file:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="__CODE_BASE_URL__" href="brmwallet.jnlp">
<information>
<title>SSL Wallet Certificates</title>
<vendor>Oracle Corporation</vendor>
</information>
<security>
<all-permissions/>
</security>
<resources>
<jar href="3plibs/wallet.jar" />
</resources>
<component-desc/>
</jnlp>
Add the JNLP file name in the resources section of the Customer_Center_Home/CustomerCenter_en.jnlp file. For example:
<resources> <extension name="brmwallet" href="brmwallet.jnlp"/> </resources>
Specify the location and name of the wallet file by adding the following entries in your Infranet.properties file packaged in a JAR file, which is specified in the <resources> section in the CustomerCenter_en.jnlp file:
- infranet.pcp.ssl.wallet.location=wallet_location/wallet - infranet.pcp.ssl.wallet.filename=wallet_name.sso
wallet_location is the wallet path within the JAR file that you created in step 1.
wallet_name is the name of the wallet file.
For example:
infranet.pcp.ssl.wallet.location=com/oracle/wallet infranet.pcp.ssl.wallet.filename=cwallet.sso
By default, the ability to use SSL/TLS with Java server processes (such as the EAI Java Server or eai_js and BRM invoice formatter) is disabled in BRM.
Important:
Only administrators with write permissions can make changes to the Infranet.properties file.To enable SSL/TLS for Java server processes:
Open the Infranet.properties file for your Java server process in a text editor.
Table 5-7 lists the default location of the Infranet.properties file for each Java server process.
Search for the following line:
- infranet.pcp.ssl.enabled=false
Change false to true.
- infranet.pcp.ssl.enabled=true
(Optional) To enable two-way server and client authentication between the CM and the Java server process, add the following entry:
- infranet.pcp.ssl.client_auth = true
(Optional) If the Java server process Oracle wallet is not in the default location, add the following entry:
- infranet.pcp.ssl.wallet.location=wallet_location/wallet
where wallet_location is the directory in which your Java server process Oracle wallet resides.
(Optional) If your Java server process Oracle wallet name is different from the sample the Java server process Oracle wallet name, add the following entry:
- infranet.pcp.ssl.wallet.filename=wallet_name.sso
where wallet_name is the name of your Java server process Oracle wallet.
(Optional) To add cipher suites for Java server process, do one of the following:
To add one cipher suite, specify the name of the cipher suite in the following entry:
- infranet.pcp.ssl.handshake.ciphersuites=cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- infranet.pcp.ssl.handshake.ciphersuites=SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- infranet.pcp.ssl.handshake.ciphersuites=SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
By default, SSL/TLS is disabled in CMMPs.
Note:
If you have multiple CMMPs on the same machine or if you are creating a new CMMP, each CMMP needs its own Oracle wallet. See "Creating an Oracle Wallet and a Server Certificate".Note:
When enabling SSL/TLS in CMMP, all the CMs listed in the redirects parameter in the CMMP's pin.conf file must be SSL/TLS enabled.To enable SSL/TLS in a CMMP:
Open the BRM_home/sys/cmmp/pin.conf file in a text editor.
Add the following entry:
- cm enable_ssl 1
(Optional) To enable two-way server and client authentication between the CMMP and the PCM client, add the following entry:
- cm ssl_auth 2-way
For information on how to create a trusted server certificate to use when enabling two-way authentication, see "Creating an Oracle Wallet and a Server Certificate".
(Optional) If your server Oracle wallet is not in the default directory (BRM_home/wallet/server), add the following entry:
- cm wallet wallet_location
where wallet_location is the full path to the directory in which your server Oracle wallet resides.
(Optional) To add cipher suites, do one of the following:
To add one cipher suite, add the following entry:
- cm cipher cipher_suite
where cipher_suite is the name of the cipher suite.
For example:
- cm cipher SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma.
For example:
- cm cipher SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
Stop and restart the CMMP. See "Starting and Stopping the BRM System".
By default, the ability to use SSL/TLS with Payment Tool is disabled. When you install Payment Tool, a sample Oracle wallet named cwallet.sso is installed in the C:\Program Files\Common Files\Portal Software\wallet\client directory.
Important:
To enable SSL/TLS for Payment Tool in Windows 7 and Windows 8.1:Only administrators with write permissions can make changes to the PaymentTool.ini file.
After enabling SSL/TLS in the PaymentTool.ini file, run Payment Tool in the administrator mode.
To enable SSL/TLS for Payment Tool:
Create a directory for the Payment Tool Oracle wallet (wallet_location).
Important:
Ensure that there are no blank spaces within the wallet_location directory name or path.Copy the cwallet.sso file from the C:\Program Files\Common Files\Portal Software\wallet\client directory to wallet_location.
Open the C:\Windows\PaymentTool.ini file in a text editor.
Add the following entry:
EnableSSL=1 SSLWallet=wallet_location
(Optional) To add cipher suites for Payment Tool, do one of the following:
To add one cipher suite, add the following entry:
SSLCipher=cipher_suite
where cipher_suite is the name of the cipher suite. For example:
SSLCipher=SSL_RSA_WITH_RC4_128_MD5
To add multiple cipher suites, separate each cipher suite by a comma. For example:
SSLCipher=SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5
By default, BRM uses SSL_RSA_WITH_AES_128_CBC_SHA. For information on cipher suites supported by BRM, see "BRM-Supported Cipher Suites".
Save and close the file.
For custom applications, use the login flist as input to the PCM_CONTEXT_OPEN opcode.
Table 5-8 lists the fields and values that you must set in the login flist to enable SSL/TLS.
Table 5-8 Login flist Fields for SSL/TLS
| Field | Data Type | Value |
|---|---|---|
|
PIN_FLD_ENABLE_SSL |
PIN_FLDT_INT |
To enable SSL/TLS, use 1. To disable SSL/TLS, use 0. |
|
PIN_FLD_SSL_CIPHER |
PIN_FLDT_STR |
Cipher suite, or cipher suites separated by a comma. |
|
PIN_FLD_SSL_WALLET |
PIN_FLDT_STR |
Path to the Oracle wallet directory. |
When SSL/TLS is enabled for secure communication between the BRM components, depending on whether the component is acting as the SSL/TLS client or as the SSL/TLS server, BRM verifies the host name configured in the SSL/TLS certificate in the following manner:
When the C and C++ PCM clients connect to the CM as an SSL/TLS server, the server host name configured in the server certificate from the CM will be verified with the cm_ptr parameter in the client's pin.conf file.
When the Java PCM clients connect to the CM as an SSL/TLS server, the server host name configured in the server certificate from the CM will be verified with the host name in the connection URL.
When the CM is the client to a DM as the SSL/TLS server, the server host name configured in the server certificate from the DM will be verified with the dm_pointer parameter in the CM's pin.conf file.
When the CM is the client to an EM as the SSL/TLS server, the server host name configured in the server certificate from the EM will be verified with the em_pointer parameter in the CM's pin.conf file.
When CMMP is used for connection between the Java PCM clients and the CM, the CMMP redirects the connection to the CM. The server host name configured in the server certificate from the CM will be verified with the host name in the connection URL.
If the host name does not match, the connection is terminated.
The server components such as the DM and EM maintain a list of trusted certificates and trusted CA certificates in the server wallet. When SSL/TLS two-way authentication is enabled for the server component, the administrator verifies the client certificate containing the host name details with the list of trusted certificates and trusted CA certificates present in the server wallet. After SSL/TLS handshake, if the certificate is used by a trusted CA, the connection is allowed. If the certificate is not used by a trusted CA, the connection is terminated.
To allow only the certificates used by Oracle CA and not any other CA, ensure that other CAs are not present in the server wallet.
You can use the PIN_SSL_DEBUG environment variable to log messages that contain debugging information related to SSL/TLS and to generate SSL/TLS trace logs.
To create debugging logs for SSL/TLS:
Set the PIN_SSL_DEBUG environment variable with the hexadecimal value described in Table 5-9. For example, to log messages that contain debugging information for SSL/TLS initialization, set PIN_SSL_DEBUG to 0x0001:
PIN_SSL_DEBUG 0x0001
To create multiple logs and trace files, use the OR function on the hexadecimal values described in Table 5-9. For example, to log messages that contain debugging information related to SSL/TLS initialization and to generate SSL/TLS trace files, set PIN_SSL_DEBUG to 0x0031:
PIN_SSL_DEBUG 0x0031
Table 5-9 PIN_SSL_DEBUG Values
| Value | Description |
|---|---|
|
0x0001 |
Logs messages that contain debugging information related to SSL/TLS initialization. |
|
0x0002 |
Logs messages that contain debugging information related to read. |
|
0x0004 |
Logs messages that contain debugging information related to write. |
|
0x0030 |
Generates SSL/TLS trace files for the CM and C and C++ PCM clients. Note: Trace logs are generated in the working directories of the respective binaries. |