File Security consideration under LANSA
| Date: | Archived |
|---|---|
| Product/Release: | LANSA for the AS/400 |
| Abstract: | File Security considerations under LANSA Authority and Ownership |
| Submitted By: | LANSA Technical Support |
Description:
Following are some considerations regarding file security when running LANSA applications on an AS/400:
- LANSA objects have two types of security settings : External and Internal.
- 1.1 Internal security is the security defined within LANSA and does not replace the external security. It is an additional security level used by LANSA. LANSA internal security will change whenever an IO module is recreated if changes have been made to LANSA internal security definitions for the file.
- 1.2 External security is the native AS/400 security
enforced by OS/400.
- When LANSA creates a file, two objects are created, the Physical file
itself and the I/O module (IOM).
- 2.1 The Physical file will be owned by the LANSA System
Owner profile:
- LANSA system owner (and its user group) will have *ALL external authority.
- The user profile (and its user group) who created the file will have all data authority, but will not have the external authority to alter the file.
- PUBLIC (the rest) will have external authority according to the "Initial public access" option in the LANSA file definition.
If only the IOM is recreated when making the file operational from LANSA, the external security is preserved.
If the physical file is recreated when making the file operational from LANSA, the external security will be overwritten as if the file was being created for the first time.
If "external security matching" (see 3.1) is not chosen, then to preserve the external security of a physical file when it is made operation consider one of the following options:- Sign on as a user who has the correct AS/400 authority (external security) to access the physical file.
- Manually change the object authority
- Grant the authority from another file. This file could hold the settings permanently (a standard or model) or it could be the previous version of the same file (with the $$ prefix).
- Write a user defined program to GRTOBJAUT, automatically. When making
a file operational there is a parameter for "User program to call at
completion". This is where the qualified name of a user defined program
is specified that should be called after the file has been successfully created or recreated. Typically
this facility is used to execute a program that initializes a new file or modifies the
data in a file that has been amended.
- 2.2 The I/O module will be
created with external user authorities of the LANSA system
owner, the user profile who created the definition and
PUBLIC. There is no internal security for IOM's. They use
adopted authority. This means that the IOM is owned and
inherits its authorities from the LANSA system owner (see
3.3)
- 2.1 The Physical file will be owned by the LANSA System
Owner profile:
- There are some common LANSA data area settings which can affect internal
and external security.
- 3.1 External Security Matching (pos. 486 on DC@A01 data area). If
byte 486 of DC@A01 is set to 'Y' and a file is created using LANSA the file will have its
external security (AS/400) set according to the LANSA internal security definitions. For
example if LANSA's internal security allows QPGMR to update and delete data in a file,
when the file is re-created, QPGMR will have external 'update and delete' data authority
at an AS/400 level.
This setting is applicable only for LANSA maintained files, not for "OTHER" files (i.e external authority for "OTHER" files will NOT be overwritten).
- 3.2 Disable LANSA file level security (pos.497 on DC@A01 data area). If
byte 497 of DC@A01 is set to 'Y' this will disable the LANSA file security checking. This means
that LANSA will not check the LANSA internal security definitions for any file.
This setting is recommended when only the external security is to be used. The access to the files is usually controlled using LANSA function level security, and it is presumed that if a user can execute a function they have authority to all the files accessed by the function.
This setting also improves the performance of LANSA applications.
- 3.3 The *IOMNOADOPT key word (in the DC@OSVEROP data area). If this key word appears anywhere on the optional
DC@OSVEROP
data area the IOM will not use the authorities as described in 2.2 . It will be created
with the USEADPAUT(*NO) option which means that the IOM will not use the program adopted
authority (as in 2.2). The IOM will use the user authority of the user executing the LANSA
function when accessing the files.
- 3.1 External Security Matching (pos. 486 on DC@A01 data area). If
byte 486 of DC@A01 is set to 'Y' and a file is created using LANSA the file will have its
external security (AS/400) set according to the LANSA internal security definitions. For
example if LANSA's internal security allows QPGMR to update and delete data in a file,
when the file is re-created, QPGMR will have external 'update and delete' data authority
at an AS/400 level.
- When considering LANSA security, there is a chain of events when
accessing any AS/400 file from IOMs. The user executing the LANSA function is at one end
of the chain and the file is at the other. If any link in this chain is broken
(restriction accessing the next object) the access will not be granted.
Example:
A user wants to add a record into a file via a LANSA IOM. To succeed in this operation, the user executing the LANSA function must have :
- LANSA internal authority to the function that calls the IOM (the function that tries to do the add).
- LANSA internal authority to the file
- external authority to the library where the IOM resides
- external authority to the library where the physical file resides
- external authority to the physical file itself.
Following are some considerations regarding file security when running LANSA applications on an AS/400 :
- LANSA objects have two types of security settings : External and Internal.
- 1.1 Internal security is the security defined within LANSA and does not replace the external security. It is an additional security level used by LANSA. LANSA internal security will change whenever an IO module is recreated if changes are made to LANSA internal security definitions for the file.
- 1.2 External security is the native AS/400 security
enforced by OS/400.
- When LANSA creates a file, two objects are created, the Physical file
itself and the I/O module (IOM).
- 2.1 The Physical file will be owned by the LANSA System
Owner profile:
- LANSA system owner (and its user group) will have *ALL external authority.
- The user profile (and its user group) who created the file will have all data authority, but will not have the external authority to alter the file.
- PUBLIC (the rest) will have external authority according to the
"Initial public access" option in the LANSA file definition.
If only the IOM is recreated when making the file operational from LANSA, the external security is preserved.
If the physical file is recreated when making the file operational from LANSA, the external security will be overwritten as if the file was being created for the first time.
If "external security matching" (see 3.1) is not chosen, then to preserve the external security of a physical file when it is made operational, consider one of the following options:
- Sign on as a user who has the correct AS/400 authority (external security) to access the physical file.
- Manually change the object authority
- Grant the authority from another file. This file could hold the settings permanently (a standard or model) or it could be the previous version of the same file (with the $$ prefix).
- Write a user defined program to GRTOBJAUT, automatically. When making
a file operational there is a parameter for "User program to call at
completion". This is where you specify the qualified name of a user defined program
that should be called after the file has been successfully created or recreated. Typically
this facility is used to execute a program that initializes a new file or modifies the
data in a file that has been amended.
-
2.2 The I/O module will be created with external user authorities of the
LANSA system owner, the user profile who created the definition and PUBLIC. There is no
internal security for IOM's. They use adopted authority. This means that the IOM is owned
and inherits its authorities from the LANSA system owner (see 3.3).
- 2.1 The Physical file will be owned by the LANSA System
Owner profile:
- There are some common LANSA data area settings which can affect internal
and external security.
- 3.1 External Security Matching (pos. 486 on DC@A01 data area). If
byte 486 of DC@A01 is set to 'Y' and a file is created using LANSA the file will have its
external security (AS/400) set according to the LANSA internal security definitions. For
example if LANSA's internal security allows QPGMR to update and delete data in a file,
when the file is re-created, QPGMR will have external 'update and delete' data authority
at an AS/400 level.
This setting is applicable only for LANSA maintained files, not for "OTHER" files (i.e external authority for "OTHER" files will NOT be overwritten).
-
3.2 Disable LANSA file level security (pos.497 on DC@A01 data area). If
byte 497 of DC@A01 is set to 'Y' this will disable the LANSA file security checking. This means
that LANSA will not check the LANSA internal security definitions for any file.
This setting is recommended when using only the external security. The access to the files is usually controlled using LANSA function level security, and it is presumed that if a user can execute a function they have authority to all the files accessed by the function.
This setting also improves the performance of LANSA applications.
- 3.3 The *IOMNOADOPT key word (in the DC@OSVEROP data area). If this key word appears anywhere on the optional
DC@OSVEROP
data area the IOM will not use the authorities as described in 2.2 . It will be created
with the USEADPAUT(*NO) option which means that the IOM will not use the program adopted
authority (as in 2.2). The IOM will use the user authority of the user executing the LANSA
function when accessing the files.
- 3.1 External Security Matching (pos. 486 on DC@A01 data area). If
byte 486 of DC@A01 is set to 'Y' and a file is created using LANSA the file will have its
external security (AS/400) set according to the LANSA internal security definitions. For
example if LANSA's internal security allows QPGMR to update and delete data in a file,
when the file is re-created, QPGMR will have external 'update and delete' data authority
at an AS/400 level.
- When considering LANSA security, there is a chain of events when
accessing any AS/400 file from IOMs. The user executing the LANSA function is at one end
of the chain and the file is at the other. If any link in this chain is broken
(restriction accessing the next object) the access will not be granted.
Example:
A user wants to add a record into a file via a LANSA IOM. To succeed in this operation, the user executing the LANSA function must have :- LANSA internal authority to the function that calls the IOM (the function that tries to do the add).
- LANSA internal authority to the file
- external authority to the library where the IOM resides
- external authority to the library where the physical file resides
- external authority to the physical file itself.
