Implementing Data Source Security

In this section:

Identifying the DBA: The DBA Attribute
Including the DBA Attribute in a HOLD File
Identifying Users With Access Rights: The USER Attribute
Non-Overridable User Passwords (SET PERMPASS)
Controlling Case Sensitivity of Passwords
Establishing User Identity

Reference:

Special Considerations for Data Source Security

You provide WebFOCUS security on a file-by-file basis. Implementing DBA security features is a straightforward process in which you specify:

The names or passwords of WebFOCUS users granted access to a data source.
The type of access the user is granted.
The segments, fields, or ranges of data values to which the user access is restricted.

The declarations (called security declarations) follow the END command in a Master File and tell WebFOCUS that security is needed for the data source and what type of security is needed. Each security declaration consists of one or several of the following attributes:

The DBA attribute gives the name or password of the Database Administrator for the data source. The Database Administrator has unlimited access to the data source and its Master File.
The USER attribute identifies a user as a legitimate user of the data source. Only users whose name or password is specified in the Master File of a FOCUS data source with security placed on it have access to that data source.
The ACCESS attribute defines the type of access a given user has. The four types of access available are:
RW, which allows a user to both read and write to a data source.

R, which allows a user only to read data in a data source.

W, which allows a user to only write new segment instances to a data source.

U, which allows a user only to update records in a data source.
The RESTRICT attribute specifies certain segments or fields to which the user is not granted access. It can also be used to restrict the data values a user can see or perform transactions on.
The NAME and VALUE attributes are part of the RESTRICT declaration.

Describe your data source security by specifying values for these attributes in a comma-delimited format, just as you specify any other attribute in the Master File.

The word END on a line by itself in the Master File terminates the segment and field attributes and indicates that the access limits follow. If you place the word END in a Master File, it must be followed by at least a DBA attribute.

Example: Implementing Data Source Security in a Master File

The following is a Master File that uses security features:

FILENAME = PERS, SUFFIX = FOC,$
SEGMENT = IDSEG, SEGTYPE = S1,$
 FIELD = SSN          ,ALIAS = SSN    ,FORMAT = A9   ,$
 FIELD = FULLNAME     ,ALIAS = FNAME  ,FORMAT = A40  ,$
 FIELD = DIVISION     ,ALIAS = DIV    ,FORMAT = A8   ,$
SEGMENT=COMPSEG, PARENT=IDSEG, SEGTYPE=S1,$
 FIELD = SALARY       ,ALIAS = SAL    ,FORMAT = D8   ,$
 FIELD = DATE         ,ALIAS = DATE   ,FORMAT = YMD  ,$
 FIELD = INCREASE     ,ALIAS = INC    ,FORMAT = D6   ,$
END
DBA=JONES76,$
USER=TOM    ,ACCESS=RW, $
USER=BILL   ,ACCESS=R  ,RESTRICT=SEGMENT  ,NAME=COMPSEG    ,$
USER=JOHN   ,ACCESS=R  ,RESTRICT=FIELD    ,NAME=SALARY     ,$
                                           NAME=INCREASE   ,$
USER=LARRY  ,ACCESS=U  ,RESTRICT=FIELD    ,NAME=SALARY     ,$
USER=TONY   ,ACCESS=R  ,RESTRICT=VALUE    ,NAME=IDSEG,
   VALUE=DIVISION EQ 'WEST' ,$
USER=MARY   ,ACCESS=W  ,RESTRICT=VALUE    ,NAME=SALTEST,
   VALUE=INCREASE+SALARY GE SALARY,$
                                           NAME=HISTTEST,
   VALUE=DIV NE ' ' AND DATE GT 0,$

Reference: Special Considerations for Data Source Security

When using the JOIN command, it is possible to bypass the DBA information in a data source. This is a security exposure created because in a JOIN structure the DBA information is read from the host Master File. This problem is solved by using the DBAFILE feature discussed in Placing Security Information in a Central Master File. All data sources in the joined structure will get security information as coded in the DBAFILE.
The DBA section of a Master File cannot have comments within it.

Identifying the DBA: The DBA Attribute

How to:

Change a DBA Password

The first security attribute should be a password that identifies the Database Administrator. This password can be up to 64 characters long and is not case-sensitive. It can include special characters. If the DBA password contains blanks, it must be enclosed in single quotation marks. Since nothing else is needed, this line is terminated by the usual delimiter (,$).

Note:

Every data source having access limits must have a DBA.
Groups of cross-referenced data sources must have the same DBA value.
Partitioned data sources, which are read together in the USE command, must have the same DBA value.
The Database Administrator has unlimited access to the data source and all cross-referenced data sources. Therefore, no field, segment, or value restrictions can be specified with the DBA attribute.
You cannot encrypt and decrypt Master Files or restrict existing data sources without the DBA password.
You should thoroughly test every security attribute before the data source is used. It is particularly important to test the VALUE limits to make sure they do not contain errors. Value tests are executed as if they were extra screening conditions or VALIDATE statements typed after each request statement. Since users are unaware of the value limits, errors caused by the value limits may confuse them.

Example: Identifying the DBA Using the DBA Attribute

DBA=JONES76,$

Procedure: How to Change a DBA Password

The DBA has the freedom to change any of the security attributes. If you change the DBA password in the Master File for an existing FOCUS data source, you must use the RESTRICT command to store the changed DBA password in each FOCUS data source affected by the change. Unless this is done, WebFOCUS assumes that the new description is an attempt to bypass the restriction rules. You use the following procedure for each data source affected:

Edit the Master File, changing the DBA value from old to new.
Issue the command:
```
SET PASS=old_DBA_password
```
Issue the command:
```
RESTRICT 
mastername 
END
```
Issue the command:
```
SET PASS=new_DBA_password
```

Including the DBA Attribute in a HOLD File

With the SET HOLDSTAT command, you can identify a data source containing DBA information and comments to be automatically included in HOLD and PCHOLD Master Files. For more information about the SET HOLDSTAT command, see the Developing Reporting Applications manual.

Identifying Users With Access Rights: The USER Attribute

How to:

Set the USER Attribute

The USER attribute is a password that identifies the users who have legitimate access to the data source. A USER attribute cannot be specified alone. It must be followed by at least one ACCESS restriction (discussed in Specifying an Access Type: The ACCESS Attribute) to specify what sort of ACCESS the user is granted.

Before using a secured data source, a user must enter the password using the SET PASS or SET USER command. If that password is not included in the Master File, the user is denied access to the data source. When the user does not have a password, or has one that is inadequate for the type of access requested, the following message appears:

(FOC047) THE USER DOES NOT HAVE SUFFICIENT ACCESS RIGHTS TO THE FILE: 
filename

Syntax: How to Set the USER Attribute

Any user whose name or password is not declared in the Master File is denied access to that data source. The syntax of the USER attribute is

USER = name

where:

name: Is a password of up to 64 characters for the user. The password can include special characters and is not case-sensitive. If the password contains blanks, it must be enclosed in single quotation marks.

You can specify a blank password (default value if not previously changed). Such a password does not require the user to issue a SET PASS= command. A blank password may still have access limits and is convenient when a number of users have the same access rights.

Example: Setting the USER Attribute

USER=TOM,...

An example of setting a user password to blank, and access to read only follows:

USER= , ACCESS=R,$

Non-Overridable User Passwords (SET PERMPASS)

How to:

Set a Non-Overridable User Password

The PERMPASS parameter establishes a user password that remains in effect throughout a session or connection. You can issue this setting in any supported profile but is most useful when established for an individual user by setting it in a user profile. It cannot be set in an ON TABLE phrase. It is recommended that it not be set in EDASPROF because it would then apply to all users.

All security rules established in the DBA sections of existing Master Files are respected when PERMPASS is in effect. The user cannot issue the SET PASS or SET USER command to change to a user password with different security rules. Any attempt to do so generates the following message:

(FOC32409) A permanent PASS is in effect. Your PASS will not be honored.
VALUE WAS NOT CHANGED

Note: Only one permanent password can be established in a session. Once it is set, it cannot be changed within the session.

Syntax: How to Set a Non-Overridable User Password

SET PERMPASS=userpass

where:

userpass: Is the user password used for all access to data sources with DBA security rules established in their associated Master Files.

Example: Setting a Non-Overridable User Password

Consider the MOVIES Master File with the following DBA rules in effect:

DBA=USER1,$
USER = USERR,  ACCESS = R ,$
USER = USERU,  ACCESS = U ,$
USER = USERW,  ACCESS = W ,$
USER = USERRW, ACCESS = RW,$

The following FOCEXEC sets a permanent password:

SET PERMPASS = USERU
TABLE FILE MOVIES 
PRINT TITLE BY DIRECTOR
END

The user has ACCESS=U and, therefore, is not allowed to issue a table request against the file:

(FOC047) THE USER DOES NOT HAVE SUFFICIENT ACCESS RIGHTS TO THE FILE:
CAR
BYPASSING TO END OF COMMAND

The permanent password cannot be changed:

SET PERMPASS = USERRW

(FOC32409) A permanent PASS is in effect. Your PASS will not be honored.
VALUE WAS NOT CHANGED

The user password cannot be changed:

SET PASS = USERRW

(FOC32409) A permanent PASS is in effect. Your PASS will not be honored.
VALUE WAS NOT CHANGED

Controlling Case Sensitivity of Passwords

How to:

Control Password Case Sensitivity

When a DBA or user issues the SET USER, SET PERMPASS or SET PASS command, this user ID is validated before they are given access to any data source whose Master File has DBA attributes. The password is also checked when encrypting or decrypting a FOCEXEC.

The SET DBACSENSITIV command determines whether the password is converted to uppercase prior to validation.

Syntax: How to Control Password Case Sensitivity

SET DBACSENSITIV = {ON|OFF}

where:

ON: Does not convert passwords to uppercase. All comparisons between the password set by the user and the password in the Master File or FOCEXEC are case-sensitive.
OFF: Converts passwords to uppercase prior to validation. All comparisons between the password set by the user and the password in the Master File or FOCEXEC are not case-sensitive. OFF is the default value.

Example: Controlling Password Case Sensitivity

Consider the following DBA declaration added to the EMPLOYEE Master File:

USER = User2, ACCESS = RW,$

User2 wants to report from the EMPLOYEE data source and issues the following command:

SET USER = USER2

With DBACSENSITIV OFF, User2 can run the request even though the case of the password entered does not match the case of the password in the Master File.

With DBACSENSITIV ON, User2 gets the following message:

(FOC047) THE USER DOES NOT HAVE SUFFICIENT ACCESS RIGHTS TO THE FILE:

With DBACSENSITIV ON, the user must issue the following command:

SET USER = User2

Establishing User Identity

How to:

Establish User Identity

A user must enter his or her password before using any FOCUS data source that has security specified for it. A single user may have different passwords in different files. For example, in file ONE, the rights of password BILL apply, but in file TWO, the rights of password LARRY apply. Use the SET PASS command to establish the passwords.

Syntax: How to Establish User Identity

SET {PASS|USER} = name [[IN {file|* [NOCLEAR]}], name [IN file] ...]

where:

name: Is the user name or password. If a character used in the password has a special meaning in your operating environment (for example, as an escape character), you can issue the SET USER command in a FOCEXEC and execute the FOCEXEC to set the password. If the password contains a blank, you do not have to enclose it in single quotation marks when issuing the SET USER command.
file: Is the name of the Master File to which the password applies.
*: Indicates that name replaces all passwords active in all files.
NOCLEAR: Provides a way to replace all passwords in the list of active passwords while retaining the list.

Example: Establishing User Identity

In the following example, the password TOM is in effect for all data sources that do not have a specific password designated for them:

SET PASS=TOM

For the next example, in file ONE the password is BILL, and in file TWO the password is LARRY. No other files have passwords set for them:

SET PASS=BILL IN ONE, LARRY IN TWO

Here, all files have password SALLY except files SIX and SEVEN, which have password DAVE.

SET PASS=SALLY, DAVE IN SIX
SET PASS=DAVE IN SEVEN

The password is MARY in file FIVE and FRANK in all other files:

SET PASS=MARY IN FIVE,FRANK

A list of the files for which a user has set specific passwords is maintained. To see the list of files, issue:

? PASS

When the user sets a password IN * (all files), the list of active passwords collapses to one entry with no associated file name. To retain the file name list, use the NOCLEAR option.

In the next example, the password KEN replaces all passwords active in all files, and the table of active passwords is folded to one entry:

SET PASS=KEN IN *

In the following, MARY replaces all passwords in the existing table of active passwords (which consists of files NINE and TEN) but FRANK is the password for all other files. The option NOCLEAR provides a shorthand way to replace all passwords in a specific list:

SET PASS=BILL IN NINE,TOM IN TEN
SET PASS=MARY IN * NOCLEAR,FRANK

Note: The FIND function does not work with COMBINEd data sources secured with different passwords.

Users must issue passwords using the SET PASS command during each session in which they use a secured data source. They may issue passwords at any time before using the data source and can issue a different password afterward to access another data source.