Consultor Eletrônico

Status: Verified

GOAL:

What does OpenEdge offer for security beyond _user?

GOAL:

Where is security in openedge?

FACT(s) (Environment):

All Supported Operating Systems
OpenEdge 10.x

FIX:

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 your data and your 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 you can do is provide features to support securing your 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. You should either get authentication from a previously established trusted source, like the operating system or ldap server etc. or directly from the user... live.

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 you would want to keep at least one record in _USER to protect access to your data.

The newer features that we offer 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.

You could write your own 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 you will probably want to 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 you to use this feature at runtime, 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 your database against unauthorized connections from an ODBC or JDBC source. Without any _USER records in place, if you start your database without specifying the broker type to be "4GL only" you leave it 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 your user authentication on the AppServer and pass back the CLIENT-PRINCIPAL to the client or, if your application strictly accesses the database through the AppServer, you could modify your AppServer connection logic to require a CLIENT-PRINCIPAL as an input parameter for repeated identification to the database of an already authenticated user.
BR>Create a _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 because with the CLIENT-PRINCIPAL model you have 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 granular you want your data security to be you may want to utilize table level security 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 you decide to use table level security, or you just want to "Disallow Blank Userid Access", you might want to choose 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 you collect the user's Userid and password, through a login dialog or a system API, you will pass this to your AppServer where it will be authenticated by your 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 your application database. If this key is to be stored in data it should be stored encrypted with a key that you determine; 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 your database. You bind the CLIENT-PRINCIPAL handle 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 you finish a request on the AppServer agent make sure you 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 your application to validate user authenticity. .