In OpenEdge 10.1A Progress Software began an initiative to offer Auditing and Security in the Database and ABL Applications. This provides our partners with some tools to integrate security into their OE Applications to offer much needed accountability. Without going too deep into this at the outset one should seriously consider contacting Progress' Professional Services Organization for assistance in drafting a security plan that fits specific environmental needs. Partners should also investigate the training course offering from Progress Education Services titled "What's new in OpenEdge 10: Auditing".
Securing data and application are multi-pronged efforts that must be constantly reviewed and updated as time passes. Security is never simply a technology, it is an ongoing process.
Security is ultimately the responsibility of the end user site of an application. As with the technology that Progress Software provides, all the application provider can do is provide features to support securing customers' data, but the implementation must be constantly checked and audited by the end user or their agent.
From most perspectives -U and –P are insufficient for security. They potentially expose usernames and passwords to even casual observers and are generally a bad idea. Authentication should either be obtained from a previously established trusted source such as the operating system or LDAP server, or directly from the user.
Currently, in OpenEdge databases, keeping at least one record in the _USER table is the only sure way to prevent unauthorized access to the database and its information. Even using the newer security features that we introduced in 10.1A, keep at least one record in _USER to protect access to the data.
The newer features that OpenEdge offers include a method for authenticating a user in ABL applications and changing the connected user's identity for use in identifying that user to a database without the need to have a _USER record for each user.
The application provider could write a custom authentication application, or call an API in an external one. This would validate the users credentials and establish that users identity at the session level and/or for each connected database individually.
Even with such a measure in place, use the table security measures which have always existed in the database to support compile time security for many Progress versions. One of the new security measures, implemented in 10.1A, allows use of this feature at run time, making it impossible for an unauthorized user to run r-code that was compiled by an authorized user to change data in a table.
Having a _USER record in place also protects the database against unauthorized connections from an ODBC or JDBC source. Without any _USER records in place, if the database is started without specifying the broker type to be "4GL only" it is open to connections from external SQL clients.
Below is one of the more ideal scenarios for working with the features that are currently available to the ABL and OE RDBMS.
Locate the database on a secure machine that is isolated from unauthorized user access, only opening up the ports necessary for database and AppServer connectivity (Consider using SSH).
Start an AppServer for authentication purposes, which handles the initial connection to the database and hands back the CLIENT-PRINCIPAL (cp) object to the client. Handle all user authentication on the AppServer and pass back the CLIENT-PRINCIPAL to the client or, if the application strictly accesses the database through the AppServer, modify the AppServer connection logic to require a CLIENT-PRINCIPAL as an input parameter for repeated identification to the database of an already authenticated user.
Create an _USER record in the database and set the option to "Disallow Blank Userid Access" under Admin >> Security in the Data Administration tool. Do not confuse this option with the "Disallow Blank Userid" option in the Database Options dialog, available under the "Admin >> Database Options" dialog, also in the Data Administration tool.
This latter option is totally exclusionary and, at this time, is not designed to work with the new security paradigm that involves using the CLIENT-PRINCIPAL object. The CLIENT-PRINCIPAL model requires a database connection prior to authentication/identification and that option prevents this. This option prevents users even connecting to the database without a Userid and password that matches what's stored in _USER.
What the "Disallow Blank Userid Access" option does is goes into the table-level data security for each table, for each permission, and prepends it with "!," thus disallowing the blank user permission to READ, WRITE or DELETE data from all database tables. This works with another option described below.
Depending upon how much granularity is required, table level security may be utilized to indicate specifically which users have access to each table and what specific access they have using this same security measure. This is available through the "Admin >> Security >> Edit Data Security" dialog which is also available through the Data Administration tool.
If table level security is used or blank userid access is disallowed, consider the new Database Option "Use Runtime Permissions Checking". This is available in the Database Options dialog under "Admin >> Database Options" in the Data Administration tool.
When the user's Userid and password are obtained through a login dialog or a system API, they are passed to the AppServer where they are authenticated by the application. This will exist only on the AppServer machine and, if it involves a database, said database should only be available for local connections.
This application should be used to authenticate the user but should also provide a key (password of sorts) to an Authentication Domain(s) registered with theapplication database. If this key is to be stored in data it should be stored encrypted with a key that is determined separately; it should not be visible in source code.
The authentication process with the CLIENT-PRINCIPAL object is based on the Security Authentication Domain(s) registered with thedatabase. The CLIENT-PRINCIPAL handle is bound to a domain(s) by registering the authenticated user and passing on the Domain's key, then sealing the client principal with a globally unique identifier (GUID).
This GUID is then passed back to the client and used for identification with the database or can be passed back and forth between the client and the AppServer for re-authentication on future trips for data.
Each time a request on the AppServer agent is completed, invalidate the client identification so that the next user to connect to the same agent does not mistakenly inherit it and authenticate mistakenly as the previous user.
For more on the CLIENT-PRINCIPAL object, and examples, please consult the Progress documentation. Specifically look at the "OpenEdge Getting Started" section, in the "Core Business Services" book. There is a wealth of information and pointers to information on how to use the new security services in an application to validate user authenticity.
