Security in OpenEdge

KMoody

KMoody

Member
(I thought I'd make a new thread since my last one was getting off topic.)

Aside from setting _File and _Field permissions for users, what mechanisms are built-in to the Progress DB and the OpenEdge language to handle security that are considered best practice in 2013?
 
Slightly off topic:

RHD, do you use SQL clients?

Also, given the changes to the CPO since 10.1C do you plan any changes to your authentication code/process after you move to 11.3?
 
Thanks! These are really good resources. I'll check them out.

Actually, I did read the documentation some time ago (must have slipped my mind!). The most useful document I found was "Deploying a Progress Application in a Secure Environment." My biggest takeaways from that were:
  • Don't allow any blank users.
  • Only allow administrators to dump and load databases. (I believe this is the default.)
  • It's best to have at least two administrators.
  • Enable runtime security so someone can't run compiled files without logging in.
  • Enforce password aging.
  • Don't include "." in the PROPATH.
Anything else?

(By the way, we're using OpenEdge 10.2b.)
 
Last edited:
Rob Fitzpatrick said:
Slightly off topic:

RHD, do you use SQL clients?

Also, given the changes to the CPO since 10.1C do you plan any changes to your authentication code/process after you move to 11.3?
Click to expand...

We don't use any SQL clients and we won't for the time being. Up until now we were able to avoid these in providing services.

Currently we are migrating to OE11.3. A change in the way we authenticate users and thus our code is on the roadmap. New, more restrict policies from our operational risk control - driven by regulatory requirements ( ... and CMA strategy - cover my a** - from senior management ) are powerful drivers to change in our authentication and authorization concept. Location aware access control, client data confidentiality, data room authorization, to big to fail and others are the buzz words of today in my company. I am just at the beginning of designing a "new" authentication and authorization concept for our solution which must be based on ASN.1 security tokens in one way or the other.

So, the goal is to have our solution ( bundle of 50+ applications ) migrated to OE11.3 first and then make fit for the new requirements. Already I've faced a stepping stone due to the changes in the CPO that break a "golden rule": You can't build a CPO in OE11.3 and authenticate against and OE10 database due to the changes in its internal structure. ( You get a silly error message stating that the authentication domain can't be found though. ) This effectively means, that you can't authenticate using the CPO with an OE11 client against an OE10 database which, IMHO of course, breaks the "golden rule" that you can always run a client of release X against a database of release X-1. This means that we need to migrate hundreds of Windoze clients and some Solaris 64Bit SPARC servers spread all over the world in one big bang. I would have preferred to migrate all clients first and then the servers step by step ...

Heavy Regards, RealHeavyDude.
 
We're in the early stages of an internal move from 10.2B07 to 11.3.1. Both _User and CP are used in various applications. I wasn't aware of the restriction on client version versus server when using CP. I appreciate the update!
 
It is a handle-based object that you can use to use to authenticate against a database instead of username/password. In order for this to work the security authentication system and domain must have been set up in the database ( you can do this via the data adminnistration tool under security ) and the client principal object must have been sealed with the secret pass phrase strored in the authentication domain.

Have a look at the CREATE CLIENT-PRINCIPAL statement.

Heavy Regards, RealHeavyDude.
 
You must log in or register to reply here.
Back
Top