2 Setting Up and Managing ASAP Security

This chapter describes the security features for Oracle Communications ASAP.

Overview of Setting Up ASAP Security Features

ASAP security is designed to provide maximum confidentiality and data integrity, while ensuring on-demand access to services for authorized users. ASAP security is designed for three essential functions: managing ASAP WebLogic-based users, securing data, and protecting diagnostics files.

ASAP provides these security functions in the following locations:

Oracle WebLogic Server security

The WebLogic Server contains default users, groups, and roles that support the various WebLogic-based ASAP functionality, like the Order Control Application (OCA) clients, the Service Activation Configuration Tool (SACT), the Service Activation Deployment Tool (SADT). Java Service Request Processor (JSRP) clients also need WebLogic Server credentials to connect to the JSRP interfaces.
ASAP server and database credential security

The ASAP environment contains a credential store factory (CSF) wallet that stores the ASAP schema user names and passwords, and the WebLogic Server user name and password. These credentials are called class A secure data. Each ASAP server can use this wallet to obtain these credentials. The CSF wallet provides both secure storage and encryption for these credentials.
Network Element (NE) credential security for Network Element Processor (NEP) to NE communication

The ASAP Control database stores credentials required for NEPs to access NEs. These credentials are called class B secure data. You can use a security tool to add, change, or delete credential information, and also to enable encryption.
ASAP system configuration parameters

Some ASAP system configuration parameters can have a significant impact on security. Parameters settings, such as diagnostic levels and server security attributes should be configured correctly to ensure data security.

Configuring WebLogic Server Security

ASAP uses the embedded Lightweight Directory Access Protocol (LDAP) server included with the WebLogic Server software to manage default ASAP users, groups, roles, and methods. For more information on this embedded LDAP sever, see the WebLogic Server documentation.

About ASAP WebLogic Users, Groups, Roles, and Methods

User security is managed with the WebLogic Server. For more information, see

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/security.html

The WebLogic Server provides the following features:

ASAP OCA client users can change their passwords. For more information, refer to the ASAP Order Control Application User's Guide.
ASAP Administrators can use the WebLogic Administration Console to add, delete, or edit users or user groups.
ASAP Administrators can use the WebLogic Administration Console to assign or unassign permissions to users or user groups.

The administrator uses security roles, method names, and principal names to configure permissions using the WebLogic Administration Console.

For information on migrating security from a previous version of ASAP, refer to the ASAP Installation Guide.

You can create, delete, and modify ASAP users and groups in WebLogic Server. For more information, see

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/security.html

Note:

ASAP requires that WebLogic user passwords have eight characters or more.

Table 2-1 lists and describes the default ASAP users.

Table 2-1 Default ASAP WebLogic Users

Default Users	Description
WebLogic_Admin	This is the WebLogic Server administrator account, where WebLogic_admin is the user name you selected when you created your WebLogic Server.
ASAP_admin	This is the default OCA client user. This user can create OCA orders, manage fallout orders, and view audit log reports in the OCA client. For more information about OCA permissions for this user, see "Understanding OCA Client Group Permissions". This user is a member of the ASAP_VNOS and ASAP_Operators groups.
ASAP_monitor	This is a default OCA client user that can be used to view OCA audit logs and reports. For more information about OCA permissions for this user, see "Understanding OCA Client Group Permissions". This user is a member of ASAP_Guests group.
ASAP_operator	This is a default OCA client user. This user can create OCA orders, manage fallout orders, and view audit log reports in the OCA client. For more information about OCA permissions for this user, see "Understanding OCA Client Group Permissions". This user is a member of the ASAP_Operators group.
asap_ws_user	User who has access to ASAP_WS_USERS_GROUP.
Cartridge_Management_WebService_MDB	User who has access to Cartridge_Management_WebService group.
cmws_studio	User who has access to Cartridge_Management_WebService group.
OracleSystemUser	Oracle application software system user.

Table 2-2 lists and describes the default ASAP groups.

Table 2-2 Default ASAP WebLogic Groups

Default Groups	Description
AdminChannelUsers	AdminChannelUsers can access the admin channel.
Administrators	Administrators can view and modify all resource attributes and start and stop servers.
AppTesters	AppTesters group.
ASAP_Guests	Allows an OCA user to login to OCA and access various methods.
ASAP_Monitors	Allows an OCA user to view OCA audit logs and reports in the OCA client.
ASAP_Operators	Allows an OCA user to creates orders, manage fallout orders, and view audit logs and reports in the OCA client.
ASAP_VNOS	The virtual network operator (VNO) group ID must be included as a member of ASAP_VNOS group. The group will be the parent of all VNO groups. This group enables the OCA client to identify and recognize a group ID as VNO group ID and therefore authorize a user as VNO user.
ASAP_WS_USERS_GROUP	Group to use role ASAP_WS_USERS.
Cartridge_Management_WebService	Group to use role CARTRIDGE_MANAGEMENT_WEBSERVICE.
CrossDomainConnectors	CrossDomainConnectors can make inter-domain calls from foreign domains.
Deployers	Deployers can view all resource attributes and deploy applications. DefaultAuthenticator.
Monitors	Monitors can view and modify all resource attributes and perform operations not restricted by roles. DefaultAuthenticator.
Operators	Operators can view and modify all resource attributes and perform server lifecycle operations. DefaultAuthenticator.
OracleSystemGroup	Oracle application software system group. DefaultAuthenticator.

Understanding OCA Client Group Permissions

Table 2-3 list and describes the ASAP permissions for OCA client groups.

Table 2-3 WebLogic Permissions for the OCA Client Groups

Method	ASAP_Operator	ASAP_Monitor	ASAP_VNOS	Enables Users to…
SA_Order_Control_Application	yes	no	yes	Access the OCA client.
SA_View_Audit_Log	yes	yes	yes	Use the audit log query function.
SA_Order_Entry	yes	no	yes	Use the order entry function.
SA_Order_Management	yes	yes	yes	Use the order management features. This includes the Work Order Query window.
SA_Abort_CSDLs	yes	no	yes	Abort Common Service Description Layers (CSDLs) in the Work Order Details window.
SA_Add_CSDL_Parameters	yes	no	yes	Add CSDL parameters in the Work Order Details window and access the CSDL Parameter dialog box.
SA_Delete_CSDL_Parameters	yes	no	yes	Delete an optional CSDL parameter from the Work Order Details window.
SA_Edit_Global_Macros	yes	no	yes	Override a global parameter to make it a local CSDL parameter and change the value in the Global Parameter dialog box.
SA_Edit_CSDL_Parameters	yes	no	yes	Modify CSDL parameter values in the Input dialog box.
SA_Insert_CSDLs	yes	no	yes	Add CSDLs to work orders (WOs) using the Select CSDLs dialog box.
SA_Release_Work_Order_Change_Due_Date	yes	no	yes	Release a WO to the Provisioning queue with a changed due date in the Release dialog box.
SA_Resequence_CSDLs	yes	no	yes	Correct the CSDL sequence using the Resequence – CSDL dialog box.
SA_Retry_CSDLs	yes	no	yes	Retry individual or failed CSDLs in the Work Order Details window.
SA_Abort_Work_Orders	yes	no	yes	Abort WOs in the Work Order Details window.
SA_Cancel_Work_Orders	yes	no	yes	Cancel WOs from the Work Order Query window.
SA_Delete_Work_Orders	yes	no	yes	Delete WOs from the Work Order Query window.
SA_View_Work_Order_Details	yes	yes	yes	Query WOs and view their details in the Work Order Details window.
SA_Release_Work_Orders	yes	no	yes	Release WOs for provisioning from the Work Order Details window.
SA_Stop_Work_Orders	yes	no	yes	Stop single or multiple WOs from the Work Order Query window.
SA_Change_Password	yes	yes	N/A	Change their user passwords.
SA_All	yes	no	yes	Access all OCA functionality (see note below) and to unlock WOs that have been locked by other users. Note: SA_All excludes SA_Change_Password. You must include the SA_Change_Password method in addition to SA_All to grant a user complete access to all OCA functionality. If you do not include SA_Change_Password, the Change Password option in the Security menu will be disabled.

Configuring Virtual Network Operator Authorization for OCA Users

The ASAP administrator should create WebLogic Server user accounts for VNO fallout managers and include their user login names under one of VNO groups. The login name of any VNO user must be a member of one or more VNO groups and one ASAP group. Below is an example of "User_A" created as a VNO operator for the "Telco 1" group and "User_B" created as a VNO monitor for "Telco 1" and "Telco 2" groups.

Table 2-4 lists and describes possible VNO user and group settings.

Table 2-4 Sample VNO Authorization

Login Name	Is a Member of	Group
User_A	is a member of...	ASAP_Operators Telco 1
User_B	is a member of...	ASAP_Monitors Telco 1 Telco 2

Is a Member of

Group

User_A

is a member of...

ASAP_Operators

Telco 1

User_B

is a member of...

ASAP_Monitors

Telco 1

Telco 2

Do the following:

Create VNO groups with unique names and add VNO groups as members to ASAP_VNOS group.
Add OCA user login names as members to one or more VNO groups. Ordinarily, an OCA user is added to one VNO group.
Add each OCA user's login name as a member to one ASAP group (ASAP_Operators or ASAP_Monitors).

VNO functionality is available to divide OCA user groups into geographic regions using the VNO_ID_DEFAULT and VNO_ID_STRIP parameters of the ASAP.cfg file.

Refer to the discussion about the Service Request Processor (SRP) Emulator Server Configuration Parameters in the ASAP Server Configuration Guide.

Configuring Authentication Providers for ASAP

During the ASAP installation process, the ASAP installer creates default ASAP users, groups, roles, and methods in the embedded LDAP authentication provider included with WebLogic Server. You can use this authentication provider to configure the default ASAP users, groups, roles, and methods, or add, delete, or modify your own users, groups, roles, and methods. You can also integrate an external LDAP server for ASAP users, groups, roles, and methods to your WebLogic Server.

Note:

You must ensure that the ASAP_VNO group name is defined in the external LDAP server.

You must perform the following steps to integrate an external LDAP server with ASAP:

Configuring an External Lightweight Directory Access Protocol Server
Configuring a Primary Authentication Provider in WebLogic Server

Configuring an External Lightweight Directory Access Protocol Server

To configure an external LDAP server for use with ASAP, use the following procedure:

Create an Administrators group in the LDAP server.
Create a user in LDAP that can be used as an administrator login for Oracle WebLogic Server.
Add the newly created user to the Administrators group.
Create the following user groups for ASAP:
- ASAP_Guests
- ASAP_Monitors
- ASAP_Operators
- ASAP_VNOS
- ASAP_WS_USERS_GROUP
- Cartridge_Management_WebService
- everyone
Note:
You may provide custom group names in the LDAP server corresponding to the seven groups mentioned in step 4.
Create users in the LDAP server and add them to the groups created in step 4.

For detailed instructions on configuring LDAP, see the LDAP documentation specific to your LDAP Authentication provider.

Configuring a Primary Authentication Provider in WebLogic Server

To configure the external LDAP server in Oracle WebLogic Server:

Configure the following authentication providers on the WebLogic Administration Console:
- Default Authentication provider
- LDAP Authentication provider
See the WebLogic Server documentation for information on configuring authentication providers.
Set the control flag as follows:
- For Default Authenticator provider, set SUFFICIENT.
- For LDAP Authentication provider, set REQUIRED.
See the WebLogic Server documentation for information on configuring authentication providers.
Reorder the authentication providers.

Note:
Ensure that the Default Authentication provider is above the LDAP Authentication provider.

See the WebLogic Server documentation for information on reordering authentication providers.

Managing WebLogic Server ASAP User Security

These procedures apply to user security that is maintained using WebLogic Server and ASAP, and assume that myrealm is the only active security realm. These procedures do not support other realms supported by WebLogic Server, such as the LDAP realm. When an administrator configures WebLogic Server with security realms other than myrealm, all features described in this section are disabled, including the change password menu in the OCA client.

ASAP administrators can configure user password policies through the WebLogic Administration Console and the Password Policy Utility page. Password policies defined in the WebLogic Administration Console include:

Minimum password length
Lockout enabled
Lockout duration
Reset duration
Lockout cache

Password policies defined in the Password Policy Utility page include:

Password aging
Password expiration warning period
Enabling/disabling password policies

If your ASAP installation includes the OCA client, observe the restrictions described in Table 2-5.

Table 2-5 ASAP Client Password Restrictions

Feature	OCA Client	Description
Password change	Supported	If the administrator has enabled password policies, users must change passwords in the OCA client.
Password change at first login	Supported	If the administrator has enabled password policies, users must change passwords in the OCA client.
Password length	Supported	Passwords must be between 6 and 21 characters in length.
Password aging	Supported	If the administrator has enabled password policies, users must change passwords in the OCA client.
Password syntax	Supported	Password syntax.
Reuse of previously-used passwords	Supported	Enforced when the user specifies a new password in the OCA client.
Lockout features	Supported	Lockout features.

The procedure for changing end user passwords is contained in the ASAP Order Control Application User's Guide.

Configuring the WebLogic Server Change Password Utility Page

Note:

Secure Shell (SSH) must be enabled on the WebLogic Server in order for the Password Policy and Change Password Utility Java server pages (JSPs) to be reachable.

To enable SSH on the WebLogic Server:

Log in to the WebLogic Administration Console.
Click Lock & Edit if not already selected. See the WebLogic Server online Help for more information.
In the Domain Structure, click on the domain.
On the Control tab, select Servers.
In the Servers table, click the name of the server to be configured.
Select the SSL Listen Port Enabled checkbox.
Provide an appropriate SSL listen port number in the SSL Listen Port field (that is BEA_SSL_PORT from the Installation Values in the ASAP Installation Guide). Ensure that this is not the same as the server listen port (that is BEA_PORT).
Click Release Configuration.
Restart your WebLogic Server.

The Password Policy page and Change Password Utility page are JSPs accessed through a web browser at the following URLs:

https://hostname:BEA_SSL_PORT/security/PasswordPolicy.jsp
https://hostname:BEA_SSL_PORT/security/ChangePassword.jsp

Note that the SSL Listen Port (configured above) is used, not the BEA_PORT value.

Note:

You must configure the BEA_WLS_HOST and BEA_WLS_PORT variables of these JSPs in ASAP.cfg. The ASAP installer populates these variables automatically during the installation process.

Setting WebLogic Server ASAP Password Policies

Administrators must set password policies using both the WebLogic Administration Console and the Password Policy page.

To define lockout conditions:

In the WebLogic Administration Console, click Lock & Edit if not already selected. See the WebLogic Server online Help for more information.
In the Domain Structure panel of the Change Center in the WebLogic Administration Console, click Security Realms.

The Summary of Security Realms screen appears.
In the Realms list, click the name of the security realm to be configured.

The Settings screen for the selected realm appears.
Select the Configuration tab, and the User Lockout sub-tab to access user lock-out settings.
On the User Lockout tab, complete the following fields:
- Lockout Enabled: Requests the locking of a user account after invalid attempts to log in to that account exceed the specified Lockout Threshold. By default, this attribute is enabled.
- Lockout Threshold: The number of failed user password entries that can be tried before that user account is locked. Any subsequent attempts to access the account (even if the username/password combination is correct) raise a Security exception. The account remains locked until the System Administrator unlocks it or another login attempt is made after the lockout duration period ends. Invalid login attempts must be made within a span defined by the Lockout Reset Duration attribute.
- Lockout Duration: The number of minutes that a user's account remains inaccessible after being locked in response to several invalid login attempts within the amount of time specified by the Lockout Reset Duration attribute.
- Lockout Reset Duration: The number of minutes within which invalid login attempts must occur for the user's account to be locked. An account is locked if the number of invalid login attempts defined in the Lockout Threshold attribute occurs within the amount of time defined by this attribute.
- Lockout Cache Size: The number of minutes within which invalid login attempts must occur for the user's account to be locked. An account is locked if the number of invalid login attempts defined in the Lockout Threshold attribute occurs within the amount of time defined by this attribute.
Click Save.
Click Release Configuration.

To set password policies:

In the WebLogic Administration Console, click Lock & Edit if not already selected. See the WebLogic Server online Help for more information.
In the Domain Structure panel of the Change Center in the WebLogic Administration Console, click Security Realms.

The Summary of Security Realms screen appears.
In the Realms list, click the name of the security realm to be configured.

The Settings screen for the selected realm appears.
Select the Providers tab and then the Authentication subtab.
In the Authentication Providers list, select DefaultAuthenticator. (The WebLogic Authentication provider is configured in the default security realm with the name DefaultAuthenticator. If you have configured a different authentication provider, select it instead.)

The Settings for DefaultAuthenticator screen appears.
Make any required configuration on the Configuration tab, including Minimum Password Length.
Click Save.
Click Release Configuration.
Access the Password Policy Utility page by entering the following URL in your web browser:

https://WebLogic_Host:BEA_SSL_PORT/security/PasswordPolicy.jsp) to access.

The Enter Network Password dialog appears.
Enter the WebLogic administrator username and password and click OK.

The Password Policy Utility screen appears.

Complete the following fields:

PasswordPolicyEnabled: Enables or disables the following password security features:

Password change, including password change upon first login, passwords being changed to a previously-used password
Password aging

Note:

The following security features are always enabled:

Lockout
Password length of 6 characters or more, but no longer than 20 characters
Inclusion of at least one special character and one number

If you disable the password policy, the password history is deleted.

Expiration Days: Specifies the period of time, in days, for which the password is valid
Warning Days: The number of days prior to password expiration that the user is notified of impending password expiration. The user is prompted to change the password.
Keep Password History: The number of previously-used passwords that are tracked in history. If the password policy is enabled, users are unable to reuse passwords tracked in history.

Click Submit.

Changing WebLogic Server ASAP User Passwords

ASAP Administrators can change user passwords at any time using the Change Password Utility JSP, provided that the system uses the WebLogic Server as the user security repository.

An administrator can also change passwords through the WebLogic Administration Console. Oracle does not recommend this because the underlying password policies, such as password length and syntax, cannot be enforced and the administrator is not notified of the policy violation.

Use of the Change Password JSP is not applicable if you are using the WebLogic Server LDAP Realm as the user security repository.

To access the Change Password JSP, you will need the following information:

Protocol for the WebLogic Server – Use of https is required to provide security.
The Change Password URL is:

https://hostname:BEA_SSL_PORT/security/ChangePassword.jsp
Root context for Security Service – By default, the ASAP installer sets security as the root context of the Security Service.

For information on the SECURITY_SERVICE configuration variable in the ASAP.cfg file, see the ASAP Server Configuration Guide.

JPasswords must contain at least one uppercase character and one number as well as one special character (that is ~ ! @ # $ % ^ & * ( ) _ + { } | [ ] \ : " ; ' < > ? , . /). This is an internal feature and is not subject to configuration.

To change user passwords:

Type the URL for the JSP, for example,

https://hostname:BEA_SSL_PORT/security/ChangePassword.jsp

The Enter Network Password dialog opens.
In the User Name field, type your user name.
In the Password field, type your password. Click OK.

The Change Password Utility window opens.
In the User ID field, type the user name of the user whose password you want to change.
In the Old Password field, type the user's current password.
In the New Password field, type the user's new password.
In the Confirm Password field, type the user's new password again.
In the Admin User Id field, enter the user ID of the Oracle WebLogic Server administrator.
In the Admin Password field, enter the password of the Oracle WebLogic Server administrator.
In the Confirm Admin Password field, enter the password of the Oracle WebLogic Server administrator again.
Click Submit. A confirmation message appears.

Disabling the Change Password Feature in the OCA Client

Table 2-6 lists the permission that applies only to the Change Password menu item in the OCA client. This feature lets ASAP Administrators disable the change password feature in the OCA client.

Table 2-6 Change Password Permission ACL

ACL	Permission
ServiceActivation.ASAP.ENV_ID. ASAP_Provisioning_Management	ChangePassword

If the new ACL is not defined in WebLogic Server, the Change Password menu item in the OCA client is disabled.

Managing Locked-out User Accounts

WebLogic user accounts have settings which automatically lock out the user for a period of time after a number of login attempts which fail due to an incorrect password. These settings are modifiable by the administrator.

To access WebLogic user settings:

In the Domain Structure panel of the Change Center in the WebLogic Administration Console, click Security Realms. In the Summary of Security Realms window, click the name of the security realm to be configured.

Select the Configuration tab, and the User Lockout sub-tab to access user lock-out settings.

See "Setting WebLogic Server ASAP Password Policies" for more details.

Settings include:

Lockout Threshold – Number of failed password entries before the account is locked. The account remains locked until it is unlocked by the system administrator, or the lockout duration period ends. The default is 5 failed password entries.
Lockout Duration – Number of minutes that a user's account remains inaccessible after being locked after Lockout Threshold invalid login attempts. The default is 30 minutes.
Lockout Reset Duration – Number of minutes within which invalid login attempts must occur in order for the user's account to be locked. The default is 5 minutes.

To unlock a locked user account:

In the Change Center of the WebLogic Administration Console, click Lock & Edit if not already clicked. See WebLogic Server online Help for more information.
In the Domain Structure panel of the Change Center in the WebLogic Administration Console, click the name of the domain.
Select the Security tab, then the Unlock User sub-tab.
Enter the name of the user to unlock and click Save.

In the Change Center of the WebLogic Administration Console, click Release Configuration.

Note:

On a Managed Server, you cannot unlock a locked account through the WebLogic Administration Console. The unlock information is propagated through a multicast message which is only configured in a cluster environment. Instead, use the following command:

java weblogic.Admin -url url -username adminuser -password adminuserpassword -type weblogic.management.security.authentication.UserLockoutManager
-method clearLockout lockedusername

Alternatively, wait until the Lockout Duration time has passed.

Updating Methods Role Assigned to a Group or User in WebLogic

This section provides information on how to update methods in an ASAP role assigned to a group or a user in WebLogic Server. You can use the information defined in deployment descriptors to grant security roles and define security policies.

You can update the deployment descriptors by using WebLogic Workshop (Eclipse component) or by editing the ejb-jar.xml and weblogic-ejb-jar.xml files manually.

To edit the XML files manually:

Navigate to WebLogic_domain/servers/WebLogic_server/upload/asapENV_ID/app (where the WebLogic_domain is the installation directory for your WebLogic Server domain, WebLogic_server is the name of your WebLogic Server domain, and ENV_ID is the ASAP environment ID.

Do the following:

jar xvf  asapENV_ID.ear ssam.jar 
jar xvf ssam.jar META-INF/ejb-jar.xml 
jar xvf ssam.jar META-INF/weblogic-ejb-jar.xml

Edit ejb-jar.xml and weblogic-ejb-jar.xml to add, remove, or modify roles to users or groups.

For example, you may remove the following three methods from the Monitor Role in ejb-jar.xml file:

<method> 
<ejb-name>ASAPSecurityServices</ejb-name> 
<method-name>SA_Aborted_Work_Order_Report</method-name> 
</method> 
<method> 
<ejb-name>ASAPSecurityServices</ejb-name> 
<method-name>SA_Activity_Report</method-name> 
</method> 
<method> 
<ejb-name>ASAPSecurityServices</ejb-name> 
<method-name>SA_ASDL_Report</method-name> 
</method>

Do the following:

jar uvf ssam.jar META-INF/ejb-jar.xml 
jar uvf ssam.jar META-INF/weblogic-ejb-jar.xml 
jar uvf  asapENV_ID.ear ssam.jar

Redeploy the asapENV_ID.ear file.

Configuring ASAP Server and Database Credential Security

Secure data must be stored in a secure location and distributed to authorized users. The ASAP security system governs how secure data is managed and the ASAP diagnostics files are secured:

Secure Data Storage

The ASAP security administrator pre-defines the nature and accessibility of secure data for each ASAP server. Class A secure data is stored in the CSF wallet during the initial ASAP installation procedures (see the ASAP Installation Guide for more information). The ASAP installer distributes this wallet to each server during the ASAP installation.
Secure Data Encryption

The CSF wallet encrypts all data contained in it and obtained from it. In addition, the CSF wallet file (cwallet.sso) has restricted access permissions.

Many ASAP utilities and scripts use the passwords contained in the CSF wallet. For more information about how these utilities and scripts use the CSF wallet security feature, see "Using the Credential Store Factory Wallet with ASAP Utilities and Scripts"

Your ASAP security administrator creates the class A secure data while installing ASAP. Your administrator can also modify ASAP Server passwords using the ModifyPasswords script (see "Changing Database Passwords in the Credential Store Factory Wallet").

About Credential Store Factory Wallet Secure Data Management

Secure data management in ASAP involves:

Setting up and maintaining secure data storage
Encrypting secure data during provisioning

Setting up and Maintaining Secure Data Storage

During the ASAP installation procedure, your ASAP security administrator must enter a predefined user name and password for each ASAP server. The administrator must also enter the WebLogic Server, and Oracle database user names and passwords. ASAP stores these user names and passwords in the CSF wallet (class A secure data).

Data Encryption

The CSF wallet provides transparent encryption features that protect all credentials it stores and transmits.

Using the Credential Store Factory Wallet with ASAP Utilities and Scripts

When the ASAP security feature is configured (security level of the Master Control server is not 0), every ASAP utility (scripts or programs) that require access to the ASAP server or database are prompted to enter a password based on the target.

The following utilities have optional arguments -P and -d for ASAP security (see Table 2-7 for more information about these arguments).

asap_recompile
asap_utils
start_asap_sys
start_control_sys
startc
starts
stop_asap_sys
stopc
stops

Table 2-7 ASAP Security Arguments

Argument	Description
-P	Used to specify the control database password and used in production.
-d	The utilities retrieve password information from the CSF wallet. The ASAP installer creates the CSF wallet during the installation of ASAP. You can modify the passwords using the ModifyPassword script (see Changing Database Passwords in the Credential Store Factory Wallet).

You can use either the -P and -d option. However, when both options are used, the -d option overrides -P.

For example:

start_asap_sys -P control_database_password
start_asap_sys => User needs to enter

control_database_password

start_asap_sys -d => Retrieve password the CSF wallet

WARNING:

The functionality to include your password in the command line when using ASAP utilities and scripts is a security risk. This functionality has been deprecated and will be removed in a future release. You can avoid this risk by omitting the password, and entering it only when you are prompted to enter it.

Changing Database Passwords in the Credential Store Factory Wallet

The cwallet.sso file is found in the ASAP_Home/install directory. This file contains security information for installation purposes and includes the ASAP database schema user names and passwords, the Oracle DBA user name and password, and the WebLogic Server domain user name and password. The ASAP installer creates this file during the installation process.

To change the CSF Wallet passwords, use the following procedure:

Source the Environment_Profile located in the ASAP_Home/ directory.
Set the TNS_ADMIN UNIX variable to the location of your tnsname.ora file.
```
export TNS_ADMIN=/home/examplelocation/
```
From ASAP_Home/scripts directory run the ModifyPassword tool.
Enter the DBA user name and password.
Enter and modify the ASAP database user names and passwords as required.

Configuring Security for Network Elements Communication

NE credentials (also called custom secure class B data) used primarily by NEPs to establish network connections to NEs must be stored in a secure location and distributed to authorized users.

The ASAP security tool supports the following features to protect NE credentials:

Secure Data Storage

An administrator can use the ASAP security tool to create NE credentials and store these credentials in a central repository on the Master Control server. The Master Control server distributes these credentials to SRPs, JSRPs, NEP, or Java-enabled NEPs (JNEPs).

ASAP stores NE credentials in the Master Control server in the tbl_classB_secu database table.
Secure Data Encryption

The Master Control server uses a symmetric secret key encryption method to achieve data confidentiality for custom secure data.
Key Distribution

The Master Control server acts as a key distribution server, and distributes custom secure data to every ASAP server during provisioning. To acquire the custom secure data, ASAP server has a pre-defined key distribution protocol.

Understanding the Custom Secure Data Structure

Your ASAP security administrator can define class B custom secure data through application programming interfaces (APIs) or action functions used by the customized SRP, JSRPs, NEP, and JNEPs. Your ASAP security administrator can also set up your custom secure data using the ASAP security tool.

The class B custom secure data typically includes the user names and password for the NEs and should only be used by custom NEPs, JNEPs, SRPs, or JSRPs.

The Master Control server contains the secure data that has name, value, creation date, and description fields. The Master Control server distributes the secure data to each ASAP server during provisioning.

Table 2-8 provides a detailed description of a secure data entry in the secure data storage. The Security Level, Alg (sdu), and Audit Level fields apply only to ASAP secure data.

Table 2-8 Secure Data Entry

Field	Type	Length	Encryption	Description
Name	Char	80	No	The name field of a secure data entry. This is used as a key to retrieve the secure data entry.
Value	Char	80	Yes	The encrypted value of the secure data entry.
Security Level	Integer		No	This field is only applicable to ASAP secure data (the class field value is 1). If the name is an ASAP server name (for example NEPab12), then this controls the level of ASAP security; otherwise this is ignored. Possible values: 0 – Turn off security feature (default). 1 – Turn on security feature. The security level of the Master Control server controls the level of the entire ASAP security. The security level of each ASAP server is only applicable when the security level of the Master Control server is not 0.
Cache	Integer	1	No	This field is only applicable to ASAP secure data (the class field value is 1. If the name is an ASAP server name, then this controls caching ASAP secure data; otherwise this is ignored. Possible values: 0 – Turn Off cache feature (default). 1 – Turn On cache feature.
Audit Level	Integer		No	Reserved for future use.
Creation Date	Date		No	The creation date.
Alg	Integer		No	The deployed secret key algorithm. The default value is 1 (BLOWFISH_ALGORITHM). The applies to the ASAP secure data only.
Class	Integer		No	The secure data classes are: ASAP secure data Custom secure data The custom SRP, JSRP, NEP, and JNEP only manipulates custom secure data.
Desc	Char	255	No	The description of the secure data entry.

For custom secure data storage, the required fields are Name, Value, Creation Date, and Desc.

Managing Custom Secure Data

Secure data management in ASAP involves:

Setting up and maintaining secure data storage
Encrypting secure data during provisioning
Key distribution (for custom secure data)
Local caching of custom secure data, for improved system performance

Setting up and Maintaining Secure Data Storage

Your administrator can set up the initial custom secure data storage repository and can predefine this custom secure data. ASAP stores this data in a central repository: the Master Control server.

Encrypting Data During Network Element Provisioning

To protect custom secure data during provisioning, symmetric or secret key encryption is used. You can use the ASAP APIs and action functions to:

Retrieve ASAP secure data and custom secure data
Update or add custom secure data

To control the security-sensitive messages that come from state table action functions, use the ACT_FUNC_SEC state table variable.

The following example shows how to use ACT_FUNC_SEC.

BEGIN TEST_PROG

110 CONCAT 'ACT_FUNC_SEC = 1'
110 DMS_LEN '%FORMAT_LEN = %MCLI:%NXX:%LEN'
120 CONCAT 'ACT_FUNC_SEC = 0'
130 CONCAT '%MY_LEN = %LEN'
END TEST_PROG

The NEP diagnostic file does not show the CSDL parameter values of NXX, LEN, and MCLI from 110 because ACT_FUNC_SEC is set to 1. The value of MY_LEN (for example, 6742727 from CSDL parameter LEN) appears in the NEP diagnostic since ACT_FUNC_SEC is set to 0 on line 120.

Any State Table action function can be placed between two CONCAT statements, but only the following action functions support the security feature:

CONCAT
DMS_FEATS
DMS_LEN
EXEC
EXEC_RPC
GET
GET_INCPT
GET_LTG
SEND
SENDECHO
SUBSTR

Understanding Key Distribution for Custom Secure Data

The Master Control server provides key distribution to every ASAP server to ensure the secure transmission of custom secure data. To acquire the secure data, the ASAP server must follow the pre-defined key distribution protocol. The Master Control server does the following:

Ensures that the implementation details of the secure data storage, such as the physical media, file location, and content, are transparent to ASAP server. By following pre-defined key distribution protocol set up by your ASAP security administrator, each ASAP server can acquire the necessary secure data.
Ensures that the secure data is accessible only to authorized users. Before requesting secure data from the key distribution server, each ASAP server authenticates itself using the session ID given by the Master Control server.
Provides a central location for secure data storage.

The Master Control server uses a one-time password named as a session ID to authenticate the requester. The session ID is the unique integer value per instance of the Master Control server.

Caching Secure Data on Local Servers

By default, each ASAP server retrieves the secure data from the Master Control server. In addition, to provide better performance in retrieving secure data, you can configure a cache that contains recently-used secure data in the local ASAP server. In this case, the ASAP server checks the local cache first, then follows the key distribution protocol. A cache provides better performance in retrieving secure data, but it can reveal secure data to unauthorized users. For example, the attacker may kill the process to generate core file and retrieve secure data from the core file.

Securing Network Element Credentials with the Security Administration Tool

You can use the command line ASAP security administration tool to set up and maintain the secure data.

asap_security_tool [–u CtrlUserID][-p CtrlPasswd]

[operation_option][-c ctrl_svr_name][-l diag_level]
[-f diag_file_name][-h]

Table 2-9 lists and describes the ASAP security tool arguments.

Table 2-9 ASAP Security Administration Tool Arguments

Arguments	Description
-u	The login ID of the ASAP security administrator (Control Database User).
-p	The password of the ASAP security administrator (Control Database Password).
operation_option	One of the operations in the Detailed Operation section that follows.
-c	The name of the Control server for the application (can be omitted).
-l	The diagnostic level for the application. The default value is LOW_LEVEL. For more information on diagnostic levels, see "Server Diagnostic Levels".
-f	The name of the diagnostic file for the application. The default is ASC_SECU.diag.
-h	Displays a help page.

All arguments are optional. When the operation_option is omitted from the command line, a menu is provided, displaying all the available operations.

The ASAP Security Utility Script provides the following options:

***** ASAP Security Utility Script *****

   1.  Initialize the secure data storage

   10. Add/Modify secure data entry
   11. Delete secure data entry
   12. Query secure data entry

   20. Import secure data from file to the secure storage
   30. Change current security level
   40. Flush secure data cache for each ASAP server

   100. Display usage message for this Tool

Enter Choice <Q - Quit>:

Note:

Selecting option 1 to initialize the secure data storage, deletes all the security data in the class A CSF wallet and the class B table. There is no way of restoring the deleted data using the ASAP security administration tool.

You can use option 1 if you want to use password encryption for class B custom secure data. Class A CSF wallet data is always encrypted.

Table 2-10 lists and describes the ASAP security tool operations.

Table 2-10 ASAP Configuration Tool Operations

Operations	Description
-i	Initializes secure data storage. With this option, the ASAP security administrator can set up class B custom secure data. Note: This operation is only available when ASAP is not running. Note: Selecting option 1 to initialize the secure data storage, deletes all the security data in the class A CSF wallet and class B table.
-x	Checks and changes the current security level. Note: this operation is only available when ASAP is not running.
-e	Flushes the secure data cache for each ASAP server.
-a data	Adds or modifies a secure data entry. ASAP data format: name:value:class:secu_level:cache_mode: audit_level: alg:description Custom data format: name:value:description You can add customer secure data while the Control server is running. When the addition of data is complete, the asap_security_tool requests the Control server to flush cached secure data.
-d data	Deletes a secure data entry. Data format: name:class You can delete customer secure data while the Control server is running. When the deletion of data is complete, the asap_security_tool requests the Control server to flush cached secure data.
-q data	Queries a secure data entry. Data format name:class
-r filename	Imports secure data to the secure data storage. To import a large amount ASAP or custom secure data into the ASAP secure storage, compose a flat file containing the essential secure data. The data format is the same as that of adding secure data. For example, a data file may contain the following secure data. Examples of custom secure data entries: TOR_NE:password1:1:0:Class B NE login info ENG_NE:password2:1:0:Class B NE login info The value field in the data file should be clear text. The ASAP security tool encrypts the data when necessary. Lines in the file starting with "#" are treated as comments.

The cache functionality is controlled by the value of the cache_mode defined for the control database login and password. The caching functionality can be changed through menu option 10 in the asap_security_tool by modifying the control database login. If the value of the cache mode for the control database login is 0, then the Control server caches the secure data. Otherwise, the Control server retrieves the secure data from the database as required.

Additional Security Considerations

In addition to the other security features, observer the following guidelines described in this section.

Setting Secure Diagnostic Levels

The ASAP diagnostic files contain information logs on provisioning activity and confidential provisioning information such as WO parameters and NE dialog as plain text. The secure ASAP diagnostic feature addresses the following key provisioning data:

NE dialog to control the content of diagnostic file
WO parameter

Setting the Network Element Dialog Diagnostic Configuration Parameter

The ASAP NEP diagnostic file contains switch-sensitive information sent and received from the NE. In production environments, Oracle recommends that the audit level is set to SANE so that switch-sensitive information is not included in diagnostics files. Oracle also recommends that you delete old archives and/or store archives in a secure manner.

In addition to setting the audit level to SANE, you can also enable or disable the configurable variable, NE_DIALOG_OFF, in ASAP.cfg. This variable controls the source code to print out all NE dialog messages from NEP diagnostic file. All the output NE dialog in the NEP application checks against the value of NE_DIALOG_OFF, and cuts off the message if the NE_DIALOG_OFF is set to 1.

Table 2-11 lists and describes the NE_DIALOG_OFF option.

Table 2-11 NE_DIALOG_OFF Configuration Variable

ASAP Configuration Variable	Default	Description
NE_DIALOG_OFF	0	Controls the NE dialog message in the diagnostic file. Possible values are: 0 – NE dialog messages appear in the diagnostic file. 1 – Secure the NE dialog. No NE dialog messages appear in the diagnostic file.

ASAP Configuration Variable

Default

Description

NE_DIALOG_OFF

Controls the NE dialog message in the diagnostic file. Possible values are:

0 – NE dialog messages appear in the diagnostic file.
1 – Secure the NE dialog. No NE dialog messages appear in the diagnostic file.

Although the NE dialog from the state table action function can be controlled by the action statement, some NE dialogs are not related to any action function, and in this case the NE_DIALOG_OFF is used to hide NE information.

Setting Work Order Information Diagnostic Levels

Work orders typically contain business sensitive information. The WO is processed by several components, like Service Request Processor (SRP), Service Activation Request Manager (SARM), OCA; consequently, the WO information is exposed to different diagnostic files. For this reason, Oracle recommends that the diagnostic level be set to SANE in productions environments to avoid unnecessarily exposing sensitive information. As well, any archival diagnostics files should be stored in a secure manner. For more information on diagnostic levels, see "Server Diagnostic Levels".

In addition to setting the audit level to SANE, you can also enable or disable the configurable variable, WO_SECURITY_PROP, in the ASAP WO. This variable controls the source code to print out the information messages from all ASAP diagnostic files for a particular WO.

Table 2-12 lists and describes the WO_SECURITY_PROP option.

Table 2-12 ASAP Work Order Properties

ASAP Work Order Property	Default	Description
WO_SECURITY_PROP	0	Controls the WO message in the diagnostic file. Possible values are: 0 – Output WO information in the diagnostic file 1 – Secure WO information. No work order messages appear in the diagnostic file.

ASAP Work Order Property

Default

Description

WO_SECURITY_PROP

Controls the WO message in the diagnostic file. Possible values are:

0 – Output WO information in the diagnostic file
1 – Secure WO information. No work order messages appear in the diagnostic file.

The WO information is output through a generic diagnostic function call, which can also output other information in addition to the WO information. A filter list controls the output. When WO_SECURITY_PROP = 1 and the message type is contained in the filter list, there is no output to diagnostic file.

All possible output message function calls that are scattered in several ASAP applications must be examined.

Note:

This security measure also applies to WO information that is fetched from the SARM database.

Securing Java or State Table NEP or JNEP to NE Connection Implementations

Since the NEP and the JNEP are designed to communicate with a variety of NEs, there are various methods used for NEP or JNEP to NE security. You can implement the Login State Table or equivalent Java method to retrieve a user_id and password from the NEP or JNEP database. The connection to the NE can then be opened with the correct identification.

Advanced State Table or Java programmers can also implement a password timeout and automatic password change functionality as requested by the switch vendor and company policies.

Setting SRP or JSRP to SARM Security Properties

Each WO within ASAP can be authorized prior to its acceptance in the SARM. The user_id and password properties are compared against the SARM database table tbl_uid_pwd.

User_id (optional) – The user_id that the SARM uses for security validation. The user_id is required if the SARM's security validation feature is enabled in the SECURITY_CHECK configuration parameter. By default, the security validation feature is turned off.
User Password (optional) – Indicates the password which the SARM uses for security validation. The User Password is required if the SARM's security validation feature is enabled in the SECURITY_CHECK configuration parameter.

Setting Security Between Servers

To increase security between Open Servers, the configuration variable CLIENT_SECURITY_ON determines whether to authorize every connection made to the Open Server. When a client (or another server) establishes a connection to a server, the user_id and password used by that connection is employed to open a connection to the SQL server. If the connection to the SQL server is successful, then the connection is accepted; otherwise it is rejected.

Enabling Schema Validation for the JSRP JMS Interface

You can enable the JSRP to validate incoming Java Message Service (JMS) XML messages at the JSRP JMS interface against the ASAP schemas that enforces xml WO message formation. Enabling schema validation helps to secure the JSRP JMS interface against invalid XML messages, but also incurs a performance impact.

To enable schema validation, set the VALIDATION_ENABLED parameter to True in the ejb-jar.xml file from srp.jar file of Domain_home/servers/server_name/upload/asapenvid.ear deployment (where server_name is the name of your WebLogic server instance, and envid is the environment ID for your ASAP instance.