2 Securing the Application

Oracle Communications MetaSolv Solution (MSS) application security consists of two processes: authentication and authorization. Authentication is the process of identifying a user with a user ID and password combination. See MetaSolv Solution Installation Guide for authentication details. This chapter provides details about authorization, the process of granting or denying access to application functions.

Note:

Security instructions provided in this chapter assume that you have chosen Oracle as the default security provider.

Planning Application Authorization

MetaSolv Solution security provides controlled, group-based access to specified parts of the MetaSolv Solution application and data. Users can be associated with groups, and users and groups can be restricted from specific areas of the software.

Figure 2-1 shows an example of group-based security.

Figure 2-1 Group-Based Security

Description of ''Figure 2-1 Group-Based Security''

Security is active when the application is installed. It cannot be deactivated. Only one user, the security administrator, has authorization to sign on. Only two groups are active at installation: Default and Sec_Admin (security).

Every layer of the architecture has predefined superusers. A superuser has full control of all functions of the architecture layer. For MetaSolv Solution, the superuser is ASAP, the only user with security permissions (the only initial member of Sec_Admin).

Learning How the Application Works

Before planning the security model and creating users and groups, learn how MetaSolv Solution works at a high level so that you understand the main functions of the product. Next, meet with representatives from each department to define areas of the product they will be using. You will assign access to the users and groups you create based on this information.

Pre-Implementation Checklist

Gather the following information before beginning to set up security for MetaSolv Solution:

Person/group responsible for setting up new user IDs, maintaining general security features/permissions
Network user ID naming conventions
Company-wide standard on password change intervals
Policy for establishing temporary user IDs
Any existing group structure in legacy systems that might be leveraged for this implementation

Designing the Security Model

A security plan must be implemented after the product is installed and before it can be used. This section describes how to make decisions about the security model and provides tools for planning the security implementation.

Designing the security model for MetaSolv Solution involves:

Identifying the most logical groups of users
Creating matrixes for listing relevant users, groups, and processes
Completing the security planning matrixes

Use planning matrixes like the one shown in Figure 2-3, "First Security Implementation Process". These matrixes give you a view of groups and permissions. Patterns become obvious and adjustments can be made before implementation.

Identifying MetaSolv Solution Users

When planning security, begin by listing all MetaSolv Solution users in the left-most column of an Employee/Group matrix. Include those users who may never enter data and only need to find information. The user name should match the Oracle user ID.

Understanding Groups and Permissions

When users are added, they are automatically members of the Default group and their security permissions are Not Set. This permission allows all users to access to all objects except security. Therefore, it is important to assign users to groups with restrictions and permissions.

Organizing users into groups eases security maintenance by reducing the number of permissions for individual users. For example, you might set up a Provisioner group, an Ordering group, and a Marketing group. If every user fits into one of those three groups, you need to set and maintain permissions for only three groups instead of for many individuals.

For a new installation, new MetaSolv Solution users are automatically added individually to the Default group and then assigned to one or more groups. The groups are given permissions to access different aspects of the product.

When a user belongs to a group, the user receives all the permissions of the group. If a user belongs to multiple groups, the least restrictive group permissions apply. A permission that is directly granted to a user overrides any group permission levels. Therefore, some users can have more or less restrictive permissions than other users in the same group if they are also restricted as individuals.

Oracle recommends always using groups to set permissions, even if it means a group might have only one member for a period of time. If your groups are well planned, other users will also be added. To routinely set permissions without using groups would require extensive setup time for implementation and ongoing maintenance for each individual. If you do not use groups, setting individual security may also require scanning too many windows and controls into the database. If you must scan objects into the database for each user, the number of records increases, increasing the possibility of negative performance impacts. This will be explained in more detail later in this chapter.

Identifying Logical Groups of Users

A quick way to designate groups within MetaSolv Solution is to identify the departments that use the product, and use those departments as the highest-level group names. If your departments are large or have diverse responsibilities, you can identify subsets of those departments as groups.

Another way to designate groups is:

Identify processes
Group processes into like functions
Map users to those groups

After determining the basic groups at your company, list them across the top of the Employee/Group matrix you used to list all user names.

Associating Users with Groups

With each user listed down the left side and each group listed across the top, fill in the matrix, associating each user with at least one group, as shown in Figure 2-2.

Figure 2-2 Security Matrix, Users and Groups

Description of ''Figure 2-2 Security Matrix, Users and Groups''

Implementing Application Security

When planning is complete, the initial process for establishing security is straightforward and sequential, as shown in Figure 2-3.

Figure 2-3 First Security Implementation Process

Description of ''Figure 2-3 First Security Implementation Process''

Before you begin implementing security in MetaSolv Solution, be sure you have completed the following tasks:

Be sure there are no user restrictions on the servers where MetaSolv Solution resides.
Make sure the MetaSolv Solution server names are in the Gateway.ini file using the parameters in "Gateway Parameters".
Assign users read-only access to the network folders containing the application files.

To access MetaSolv Solution security:

Log in to MSS.
Click Administration on the navigation bar.

You can now add users, assign MetaSolv Solution permissions, and maintain groups. The rest of this chapter and the online Help provide details about procedures and descriptions of window and fields.

Adding New Users and Groups

All users are initially members of the Default group and can remain in that group even when assigned to other groups. The Default group is initially restricted only from accessing security.

Both users and groups can be members of groups. A user or a group can be unassigned from any group with which it is associated. Make sure that the unassigned user or group does not need the permissions being removed when it is disassociated from the parent group.

To add users or groups:

Log in to MetaSolv Solution using the ASAP ID and password.
Click Administration.
Click Security Users and Groups.
Click Users or Groups in the left pane.
Right-click in the right pane.
Click New or New From, which opens the dialog for adding a new user.
Accept the 90-day default password expiration date by taking no action, or change it based on your business practices
Follow operation instructions in the Help for adding new users or new groups.

Note:

If you are using a non-Oracle security scheme for authentication, add the user using the application provided by the third party.

Authorizing System Administrators

Table 2-1 lists the administrator privileges and provides information on how to assign each privilege to authorize users.

Table 2-1 How to Assign Administrator Privileges

Authorization	How to Authorize
DBA identification	Scripts are run during installation that provide the ASAP user with DBA authority. Use the ASAP user ID to perform MetaSolv Solution DBA tasks.
Security administrator	Add the user's ID to the Sec_Admin group or to another group that has some or all security permissions. See "Creating Additional Security Administrators".
Access to configuration files	Master configuration files reside on the Oracle WebLogic server. These files can be edited by any user unless password-protected by the IT department. When distributed to client machines, configuration changes can be made.
Customize default desktop	Log on with the ID specified in the DefaultPortalId parameter of Gateway.ini file.
Customize default portlets	Log on with the ID specified in the DefaultPortalId parameter of Gateway.ini file.
Customize the navigation bar (Navbar)	The user identified in the User parameter of the Gateway.ini in the JNDI section can set the Allow Users to Customize My Desktop preference in MetaSolv Solution. This default determines whether users can customize the desktop Navbar, according to the instructions in the Help.
Set system and global preferences	A user can be assigned permission within application security to set these preferences that affect user setup in the MetaSolv Solution database. Instructions are in the online Help.
Manage Oracle WebLogic Server	See the Oracle WebLogic Server documentation for information on authorizing administrators.

Validating API Logons

Some MetaSolv Solution API servers, such as PSR, LSR, and Work Management, have security features that can be enabled using optional parameters in the Gateway.ini file.

To turn on logon validation for an API server, add the following parameters to this section of the gateway.ini file, as in the following sample lines:

validateUserAndPassword=true
secureServer_Name=true

Where Server_Name is a recognized server name. See "OrbProperties Parameter" for details.

These parameters work only if you are sending a ConnectReq CORBA object to the WDIRootImpl object. This does not apply to all APIs, because some, such as the ASR API, do their own transaction management.

Refer to the CORBA API Developer's Guide for details about coding the APIs. See "OrbProperties Parameter" to set up API logon validation.

Adding Registered Users to MSSRole for Accessing EJB Methods Externally

The MSS application implements security for EJB methods. You must add a registered user to the Global Role MSSRole to access the EJB methods externally.

To add a registered user to MSSRole:

Log on to the Oracle WebLogic Server Administration Console by entering the following URL in your browser:
```
http://host:port/console
```
where:
- host is the name of the administration server machine.
- port is the administration server port number.
Create a user with the registered user name. See the WebLogic Server documentation for detailed information on creating users.
Add the registered user name to MSSRole. See the WebLogic Server documentation for detailed information on adding users to roles.

Adding Registered Users to MSSJMSRole for Accessing External JMS Queues

The MSS application implements security for external JMS queues. You must add a registered user to the Global Role MSSJMSRole to access the external JMS queues.

To add a registered user to MSSJMSRole:

Log on to the Oracle WebLogic Server Administration Console by entering the following URL in your browser:
```
http://host:port/console
```
where:
- host is the name of the administration server machine.
- port is the administration server port number.
Create a user with the registered user name. See the WebLogic Server documentation for detailed information on creating users.
Add the registered user name to MSSJMSRole. See the WebLogic Server documentation for detailed information on adding users to roles.

Note:
The JMS user, APP_JMS, has been created for security purposes. Do not modify or remove this user.

Tracking Logons

The appserver_auditlog.xml log file can tell you when users log on and off and when there are failed attempts. This capability can be used to identify unauthorized access attempts. Review the material in "Setting the Loggingconfig.xml Parameters" and the sample configuration file in "Annotated Loggingconfig.xml" for instructions on setting the configuration and for a sample configuration file. "Managing MetaSolv Solution Log Files" provides instructions for viewing the log file.

The following example shows the different types of audit messages recorded in this log file for logon/logout actions from a fictitious user ID named SCHINTAL.

Authentication failure

Message:
```
Login attempt failed for SCHINTAL. Exception: ORA-01017: invalid username/password; logon denied
```
Cause: Invalid username and/or incorrect password.

Action: Please supply correct user/password.
Authenticated (successful)

Message:
```
Login detected for SCHINTAL.
```
Cause: User has signed on.

Action: None.
User has signed off

Message:
```
Logout detected for SCHINTAL.
```
Cause: Logout by user or Client disconnected.

Action: None.

Managing Application Passwords

The security administrator manages the following application password tasks:

Setting the password preference
Specifying password expiration dates
Resetting passwords
With Oracle authentication, creating a new Oracle user ID for APIs to use when accessing the database

Setting the Password Preference

To set the password preference:

Log in to MetaSolv Solution.
Click Administration.
Click Preferences.
Double-click the Security folder.
Double-click the Change password upon initial logon preference.
(Optional) To require a password change at the first logon, select Change password upon initial logon.

Specifying a Password Expiration Date

To specify a password expiration date when adding a user:

Log in to MetaSolv Solution
Click Administration.
Click Security Users and Groups.
Do one of the following:
- To add a user and accept the 90-day default password expiration date, retain the defaults.
- Change the default password expiration date based on your business practices.

At any time after a user has been added, you can set a specific password expiration date or specify that the password does not expire.

Maintaining User Passwords

To assign or change a password expiration date for an existing user:

Click Administration.
Click Security Users and Groups.
Double-click the user whose password expiration date you want to specify.

The Edit User window is displayed.
Click the Password Expires On field, which displays the current calendar.
Do one of the following:
- Select a date.
- Clear the field to indicate no expiration date.
Click OK.

Creating Additional Security Administrators

To create additional administrators:

Log in to MetaSolv Solution.
Click Administration.
Click Security Users and Groups.
Add the user to the Sec_Admin group or create a new sub-group for Sec_Admin.

You can create sub-groups with subsets of permissions, such as:
- Access to the Security Permissions window
- Access to Security reports
- Access to the Users and Groups window
- Access to work management task editing
- Access to the security system preference
- Users to change global preferences

Assigning MetaSolv Solution Permissions

Permissions are controlled through the MetaSolv Solution UI. Permissions control what users and groups can access in the application. Permissions (inclusive or restrictive) are assigned as a means of controlling feature access and on-screen displays. Features and windows can be disabled and fields can be made invisible.

To access permissions:

Log in to MetaSolv Solution.
Click Administration.
Click Security Permissions.

The Security Permissions window appears.
In the left-most pane, expand the menu tree to display a long list of MetaSolv Solution windows.

The right-most pane displays a list of permissions for the user or group displayed in the User/Group list.
Follow directions in the online Help to assign permissions.

Understanding Permissions

Permissions determine what a user can do and which items can be seen within the application. Permissions can be assigned to a group or to a specific user.

The rules for determining access include the following:

When a user is assigned to multiple groups, the least restrictive group permissions apply.
Not Set allows access to objects as a default.

When an individual user is assigned a permission, it overrides group permissions.

Different objects are associated with different types of permissions. The next sections describe the permissions for each type of object.

Window Permissions

There are four levels of permissions that you can assign to a window:

Read Only: Users can see and access the window but cannot make changes.
Enabled: Users have explicit permission to use the window and make changes.
No Access: Users cannot see or use the window.
Not Set: Users can access the window. It is similar to Enabled, but it does not override other permissions when the system determines the least restrictive permissions for a user.

Control Permissions

Objects such as lists, tree view buttons, tabs, columns, check boxes, and fields are known as controls. Control names are not preloaded into the MetaSolv Solution database.

If you want to secure a control and the name does not appear in Security, it does not exist in the MetaSolv Solution database. To add the control to the database, refer to "Scanning Windows and Controls Into the Database".

Controls are associated with the following permissions:

Enabled: Users have explicit permission to access the control and make changes.
Disabled: The control is non-functional.
Invisible: The control is grayed out.
Not Set: Users can access the control. It is similar to Enabled, but it does not override other permissions when the system determines the least restrictive permissions for a user.

Pop-Up Menu Permissions

You can secure an entire pop-up menu or a specific item on a pop-up menu. Pop-up menus are preloaded into Security and cannot be added or customized other than setting permissions.

Pop-up menus are associated with the following permissions:

Enabled: Users have explicit permission to use the pop-up menu and make changes.
Disabled: The pop-up menu is non-functional.
Invisible: The pop-up menu does not appear.
Not Set: Users can access the pop-up menu. It is similar to Enabled, but it does not override other permissions when the system determines the least restrictive permissions for a user.

Check Point Permissions

Check points secure certain logical functions in MetaSolv Solution that do not correspond to window objects. Because these functions can have far-reaching impacts, check points are preloaded into Security and cannot be added or customized. The Sec_Admin group can access all security check points.

The following processes are protected by check points:

MSAG Override settings
Cascade Reconcile
Mass DLR Reconcile
IP Addresses - External
Reset Supp Type
Order Management: w_row_in_use
PSR External Service Key
Security Permissions
Security Users and Groups
Users and Groups
Security Reports
Partition Groups
Assign Permissions
Preferences
Software Options
Password Policy
PBDatabaseTrace
Shared Views
Exception Queue Access
View All Work Queues
Edit Tasks
System Queue Access
Encrypt Passwords

Note:
At installation, only the security administrator has the ability to change a completion date on the Work Management Work Queue Manger window - Task Detail tab. The security administrator can assign that access to groups or users using the Edit Tasks check point.

Permissions that can be assigned to check points are:

Enabled: Users have explicit permission to pass the check point.
Not Set: Users can access the window. It is similar to Enabled, but it does not override other permissions when the system determines the least restrictive permissions for a user.
Password: Users must enter a password to pass the check point.

No user outside of the Sec_Admin group can pass a check point without the security administrator providing explicit permission to access the protected object or function and providing a special password for the pop-up that appears when trying to access the area. The Sec_Admin group can access all security check points.

Scanning Windows and Controls Into the Database

The list of windows in the Security Permissions window uses development window names and not the names that appear on the UI. The list contains all of the JSP windows in the application and many PowerBuilder windows. Not all PowerBuilder windows are listed. If a window you need is not listed, you can scan the controls on the window into the MetaSolv Solution database and then assign permissions to those controls.

To scan a window:

Open the window containing the controls you want to secure.
Press F2.
Make a note of the highlighted window name when the dialog box appears.
Assign permissions to the controls on that window using the Assign Permissions window.

Creating MetaSolv Solution Security Reports

Security reports provide information on the aspects of MetaSolv Solution system security, as listed in Table 2-2.

Table 2-2 Security Reports

Report	Description
Individual Detail	Lists controls and statuses for the selected user or group
Hierarchy Detail	Lists controls and statuses for the Ancestor Hierarchy of the selected user
Ancestor Hierarchy	Shows the parent groups of the selected group/user, recursively
Descendant Hierarchy	Shows the groups/users who are assigned to the selected group
User Exception	Shows users who are not members of the Default group

See the online Help for detailed instructions on creating security reports.

Managing Utilities Security

A separate authorization is required to access security in the Tbs_util.exe file, the MetaSolv Solution utilities. Leaving the utilities unsecured allows an authorized user to purge database records. See the online Help for instructions on using the MetaSolv Solution utilities security feature.

Managing File Permissions

On UNIX systems, the newly created files are given minimum permissions and only the owner can read, write, or execute these files (umask has been set to 0077 for the installer).

Table 2-3 lists the custom permissions that the installer grants for specific file types.

Table 2-3 Custom Permissions

Folder	Owner	Group	Other
config	read and write	read and write	-
ior	read and write	read and write	read and write
gateway	read and write	read and write	-
logs	read and write	read	read
sample	read, write, and execute	read, write, and execute	-
others	read, write, and execute	-	-

Note:

On Windows systems, the system administrator must review the installation folders and restrict file permissions.

Changing Role Passwords

Only the database administrator can change passwords for the roles ADMIN_ROLE and WOTSTWTWWOO by running the following stored procedure:

===========pl/sql should be run by dba for changing role's password==========
DECLARE
  C_NAME VARCHAR2(200);
  C_PASSWORD VARCHAR2(200);
BEGIN
  C_NAME := 'role_name'; /*specify the role name, ADMIN_ROLE OR WOTSTWTWWOO*/
  C_PASSWORD := 'password'; /*specify the password*/
  SP_CREDSTORE_CHG_ROLE_PWD(C_NAME, C_PASSWORD);
END;