Feedback
Did this article resolve your question/issue?

   

Article

What is the difference between Disallow Blank User (compile-time) security and Disallow Blank User (run-time) security?

« Go Back

Information

 
TitleWhat is the difference between Disallow Blank User (compile-time) security and Disallow Blank User (run-time) security?
URL Namedifference-between-Disallow-Blank-User-compile-time-security-and-Disallow-Blank-User-run-time-security
Article Number000153290
EnvironmentProduct: OpenEdge
Version: 10.1B or later
OS: All supported platforms
Question/Problem Description
What is the different between Disallow Blank User under Security and Database Options
What is runtime security checking and compile time security checking?
Why are Disallow Blank User (compile-time) security and Disallow Blank User (run-time) security different settings?
Steps to Reproduce
Clarifying Information
Database Administration > Admin > Security > Disallow Blank Userid Access
Database Administration > Admin > Database Options > Disallow Blank Userid
Error Message
Defect Number
Enhancement Number
Cause
Resolution
OpenEdge 10.1B introduced a new Option to the Data Administration (Windows) user interface or the Data Dictionary (Unix) user interface under the Admin menu: Database Options, a toggle box option to select Disallow Blank Userid.  
  • When enabled, the database will only allow connections from a user if the user provides a username and password.
In previous versions, only the Disallow Blank Userid Access Option under the Admin, Security menu was available.  
  • When enabled, this Option adds the "!,*" value to table security information to prohibit a blank user from accessing table data.  
  • When a non-blank user connects to the database then that user will be able to access data within the database tables.
  • A non-blank user which already has access to table data can write and compile code against the table. The userid of the user which compiled the code will be embedded in the r-code. From that point forward, that code will always be able to access the table(s) data unless “Database Options > Disallow Blank Userid” prohibits a blank user connection.
Without Blank Userid Security enabled, when a user connects to a database with the default blank user identity, the user potentially has full access to the database.  To prevent users with a blank user ID from gaining unauthorized access to an OpenEdge database one of the following two options (or both) may be chosen starting with OpenEdge 10.1B:

Option 1:  Disallow Blank User (run-time) security
 
Admin > Database Options > Disallow Blank Userid 

Setting the Database Option to Disallow Blank Userid Connections, in which case the User ID (-U) parameter and a non-blank user ID and password are required to connect to the database

Option 2:  Disallow Blank User (compile-time) security

Admin > Security > Disallow Blank Userid Access 

Setting the Security Option to Disallow Blank Userid Access, prevents a blank user from writing and compiling code against tables if that user does not have rights to the table.  However, application code which was compiled by an authorized user will still be able to be run against the database even if the current user doesn't supply a user and password.

The first Option, Disallow Blank User (run-time) security, prevents blank users from connecting to the database in certain, but not all, scenarios;
The second Option, Disallow Blank User (compile-time) security, prevents blank users from accessing any data in the database by explicitly revoking blank user ID access to all data in the database.  
These two Options together provide the most comprehensive protection from unauthorized access by a blank user.  In addition, the Database Options, "Use Runtime Permissions Checking" can be enforced. For further information refer to Article:
Non-blank user IDs must be assigned to the Security Administrator Role before restricted access to blank users is applied.

Always take a database backup prior to undertaking any maintenance, especially in this area of security.
 
Workaround
Notes
References to Other Documentation: 

OpenEdge Development: Programming Interfaces, "Application Security"
OpenEdge Deployment: Managing ABL Applications, "Database table- and field-level security"
OpenEdge Development: Basic Database Tools, "Admin Menu Reference: Database options"

Progress Article: 

 How to prevent users other than the Administrator from accessing the schema  
 
Last Modified Date11/20/2020 7:24 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.