File Security consideration under LANSA

Detailed Description:

Following are some considerations regarding file security when running LANSA applications on an AS/400:

1. 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.
2. 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.

     The external security settings of a file may change when the file is made operational.

     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).

1. 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.
2. 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 :

1. 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.

    

2. 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.

     The external security settings of a file may change when the file is made operational.

     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).
3. 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.
4. 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.