Concept for Restricted Read Access (RRA)

With RRA the central routines handling the database access are enhanced to supply an additional layer of access control added on top of the multi entity logic already implemented in the software.

The implementation of the access control is done in a single core routine where the specific semantic of the access control generates a filtering SQL condition with the intention to restrict the accessible entries to those entries readable be the current user.

The basic idea consists on the following ideas

1. A table where the access shall be restricted holds an additional column RRALEV. This RRALEV holds the relevant control information to control the access to the single entries enabling a data driven access control for each entry in the table.
2. The rule “SdbEtyGenRraCon” generates a SQL condition fitting to the semantics defined for a customer. This rule is automatically included in Ety-SQL used to access the database.
3. A module below SYSMOD (usually the user) holds additional information to be able to restrict the access as needed.
4. If additional data is necessary (like list of allowed users) these information is stored in fields beside the RRALEV field in the table which needs restricted access.

The field RRALEV is intended to hold something like an access or security level for each individual entry.

If this field holds the default value (which usually is space) the default access rights are valid. The default access rights might be readable for everybody or readable only for a special group of users. Thus the default access right is not always, everybody may read everything.

If certain transactions are intended to operate globally and thus do not utilize the multi entity routines the routine “SdbEtyGenRraCon” might be called separately to retrieve a potential necessary RRA-restriction condition.

The concept is utilized at CS and UBS in customization.

1. Affected table (Contract + TRN + SPT . . . .) hold the field RRALEV and the RRAUSRLST with a list of allowed users.
2. Completion Screen of contracts allows to Set the Contract protection Flag (= RRALEV) together with the list of users allowed to access the contract.
3. When storing the contract the RRALEV and RRAUSRLST of all attached table is updated, when the content has changed.
4. “SdbEtyGenRraCon” creates the SQL for a table there RRALEV is existing: ( RRALEV = ‘ ‘ or ( RRALEV > ‘ ‘ and RRAUSRLST like ‘%-‘ + \SYSMOD\USR\EXTKEX + ‘-%’ )
5. RRAUSRLST holds the User-Ids of the users with a minus as delimited between the user-ids (incl. a leading and trailing minus character)

Results in classified contracts are invisible to users not listed in the user-ids of the contract.

1. Affected table (Contract + TRN + SPT . . . .) hold the field RRALEV.
2. Each User holds a security level he is assigned to. (RRASTA)
3. When storing the contract the RRALEV of all attached table is updated, when the content has changed.
4. RRALEV of a contract is initialy set to the RRASTA of the contract creating user
5. “SdbEtyGenRraCon” creates the SQL for a table there RRALEV is existing: RRALEV >= SqlLit( \SYSMOD\USR\RRASTA )

Results in contracts are only visible to all user of the own security level or above.