My understanding of CLIENT-PRINCIPAL objects is that they are well-suited for distributed applications, allowing the server-side database connection to use one user ID (with R/W privilege) and the client session to use another user ID (without R/W privilege).
I'm wondering if anyone has ideas and/or experience using CLIENT-PRINCIPAL security in a client/server session with a database connected to the client session. I'd like to prevent the client user from having Procedure Editor access to the connected database (assume that the client is a Development license). I've toyed with using SET-DB-CLIENT before and after a database read or update, but with SDOs it seems to me that there are too many before, if it fails during, and after points to manage the database user ID (especially queries).
Is protecting a session-connected database from direct user query/update in a development session realistically possible, or should I quit while I am behind?
Is there a reason that you wouldn't program this in the AppServer "activate" procedure? (or connect if you're using state-aware or state-reset)
Oh, it works out very well in an AppServer "activate" procedure. I'm just wondering if there is a way to implement a similar security scheme in a client/server (i.e. OE client connected to the application database) implementation.
Many users of our application run in C/S mode. As we intend to enhance security (nicely done with CLIENT-PRINCIPAL objects in a distributed session), I'm somewhat hestitant to say to them that the new security enhancements are simply not available for C/S implementations.
However, since there's no euqivalent (that I know of) to an activate procedure in a client session, it makes a similar security system improbable in that environment. Was hoping that someone could confirm or deny my assesment.
Sorry about the long delay before replying, but I was pretty busy with Exchange.
If you're in a client/server situation, you should be able to just instantiate and seal a CLIENT-PRINCIPAL at the start of your session. That way it's active for the duration of the session.
Now if you change userids or operating company, etc. during a session, you have to consider whether it's better to instantiate and seal a new CLIENT-PRINCIPAL each time such a change is made (so you only have one valid CLIENT-PRINCIPAL at any given point in time) or whether you might want to create a new CLIENT-PRINCIPAL only on the first change and then simply manage them correctly when the change is made.
Each approach has it's upsides and it's downsides.
Thanks for the reply. Exchange was keeping me busy, too.
Indeed, using a CLIENT-PRINCIPAL object in client/server is definitely valid. The challenge, though, in client/server is giving the application access to the application database without giving the user access to the database - so that the user cannot directly manipulate data.
In distributed mode, giving only the application database access is fairly simple, since the database connection belong to a completely different session than the client session. It could even be done without CLIENT-PRINCIPAL objects, but the CP objects sure make things easier.
As with the subject of this post, SDOs make the client/sever environment even more challenging. Since their seems to be so many potential database access points, it would be difficult to constantly change the DB user ID back and forth between the "application user" (with can-read and can-write permission) and the "human user" (without can-read and can-write permission).
I've given some thought to using table triggers to check the name of the calling procedure or similar mechanism, but it would have to be one that is not easily circumvented. I've given even more thought to abandoning the idea of implementing distributed-type security in a client/server session, since it is likely to require coding much different than the distributed mode.
The answer seems to be that you can't get there from here - it is seemingly impossible to allow a client/server user access to a database through an application, but not via the Procedure Editor or other non-application code.
actually, the procedure editor is a 4GL application, which is part of the issue you're having - there's no way to discern between an "application" and "not an application" when they're both based on ABL code.
I'm not sure what your issue is here. If you don't lock down access via the editor, then you really can't assure much of anything, can you? So, all that means is that access to the editor and database has to be rigidly limited. Likewise, if you are going to apply your security to reading data as well, then you can't really have SQL clients rummaging around in there either, can you?
So, if you lock down the DB, SQL, and the procedure editor, then the only way to get at the database is via the application. There you apply security. Indeed, you can do some simple things like define a single _User record and use that for all database connections, but don't give out that password and don't define any other users.