How to clear an Appserver identity - Forum - OpenEdge Development - Progress Community

How to clear an Appserver identity

 Forum

How to clear an Appserver identity

This question is answered

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? 

Verified Answer
  • You don’t.  You should ALWAYS have a user asserted in the session. Always.
     
    Create a low-privilege user and assert it in the appserver (session) startup, before you do almost anything else.
    In activate, you assert the incoming request’s user and do the work
    In deactivate, you assert the low-privilege user.
     
All Replies
  • I think this conversion is more around how to work with a tokenized user (ie CP) rather than how we know which user (session-id or b64-encoded-cp or something else).
     
    You should really use the CP as a user token in ABL.
  • 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

    Roundtable Product Architect

    www.roundtable-software.com

  • 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. 

  • “user accounts” can be stored in _User or one of your own db tables. The principal remains the same regardless: if the  user accounts and the business data are in the same DB and if that db is stolen/hacked then an attacker has the keys (users) and the valuables (data) all together. 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.
     
    The _user table is something like 30 years old. Times and recommended practices change; that taken together with keeping things from not breaking is at least (partly) why it still exists in the OE db.
     
     
  • ".. 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). :)

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • knowledgebase.progress.com/.../Calling-SECURITY-POLICY-SET-CLIENT-to-log-out-worked-in-OpenEdge-10-x-fails-in-11-x

  • 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...?

  • Very good point!

    Sent from Nine

    Von: ske <bounce-ske@community.progress.com>
    Gesendet: 26.01.2017 7:23 vorm.
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] How to clear an Appserver identity

    Update from Progress Community
    ske

    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...?

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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

    www.vidisolve.com

  • Is this an issue that can happen with an appserver? I would think the activate / deactivate triggers would catch any contingencies that could happen.