I've got a system in place to assert a user identity during an appserver call, and I want to de-assert that identity in the call deactivate procedure.
Since SECURITY:SET-CLIENT(?) is illegal, what is the normal way to de-assert a user identity for an ABL session?
Progress-folks like to say this:
"..(and you should really never store user accounts in application/business databases)."
But, I've never a good explanation for why that is.
What *is* the purpose of the _user table if it is not for users?
I am far from being a security expert so please excuse my elementary-level understanding.
Jeff Ledbetter Product Architect | Roundtable Software
Here's some samples lines from my .lg
[2017/01/25@14:22:11.570-0500] P-1004 T-7344 I APPSRV 8: (452) Login by SYSTEM on batch.
[2017/01/25@14:22:11.578-0500] P-1004 T-7344 I APPSRV 8: (7129) Usr 8 set name to .
[2017/01/25@14:22:11.606-0500] P-1004 T-7344 I APPSRV 8: (7129) Usr 8 set name to restricted.
who/what/how is this name set to ""?
"restricted" is code I've got running.
"..(and you should really never store user accounts in application/business databases)." -
I expect security since any code in the app can get to them. Ditto for D&L, etc.
The usual suggestion is to store that info on a secure, separate server and make calls that server to handle identity & authentication stuff.
".. People are generally bad at storing passwords so there’s a real risk of losing your data. If the user accounts are held separate from the data then the attacker only has part of what they need."
"It’s also a good separation of responsibilities to keep the user accounts separate from the business data IMO"
Okay, those makes sense.
We have never been able to successfully implement the CLIENT-PRINCIPAL object nor quite grasp the intricacies outlined in the 'Identity Management' guide, so my opinion is probably worthless on this subject (and most other subjects). :)
Wouldn't one difference between being able to clear the user or setting a low-privilege user, be that clearing the user should be an operation that never can fail? What do you do if setting the low-privilege user fails, for whatever strange reason...?
You received this notification because you subscribed to the forum. To unsubscribe from only this thread,
post as spam/abuse.
Architect of the SmartComponent Library and WinKit
That is exactly my point. I've seen cases in the current model where When setting the low-privilege user fails for any reason, the previous higher privilege user remains in effect. If the next call fail so set a user, auditing will then record everything as if it was done by the previous user. Which auditor will be happy with that?
Progress says the audit trail is irrefutable, but it is not. Even a minor glitch in your handling of the security will result in blaming the wrong user.
I would rather see a clearly defective audit trail of unauthenticated/unknown users doing things, which alerts me to the fact that I have a problem, than having an apparent perfect audit trail which actually blames the wrong users with no proof of the defect.
After all, the blank user / any user in an invalid state should have no privileges beyond what is needed to get authenticated in any case, but that is up to the application/framework programmer and prone to defects that you really want to be able to detect early and with ease.
Simon L Prinsloo
Is this an issue that can happen with an appserver? I would think the activate / deactivate triggers would catch any contingencies that could happen.