CA-414418: Sessions do not got destroyed after domain user been removed and performance improvement

[liulinC]

commit 92377bfe2fffd762ab922a015a93afa314ae000f (HEAD -> private/linl/CA-414418, origin/private/linl/CA-414418)
Author: Lin Liu <[email protected]>
Date:   Thu Jul 31 07:25:30 2025 +0000

    CA-414418: Perf: save user validate result and apply to sessions
    
    For all sessions created by external/AD users, session revalidate
    will check whether the users are still acitve, and kick off the
    session accordingly.
    
    However, xapi check the user for every session. The problem here
    is lots of session are created by only a few users. (for the case
    of CVAD and ControlUP). This would cause lot of duplicated check
    for the same user again and again, which is slow and waste lots
    of resources.
    
    To fix the issue, [(user_sid, check_result)] is defined for every
    round of check. The check result is saved so later check for the
    session with same user can just be applied.
    
    Signed-off-by: Lin Liu <[email protected]>

commit b0e2b5bfd2791dfa38ee9e4c9cd9480f7a01016e
Author: Lin Liu <[email protected]>
Date:   Thu Jul 31 06:17:32 2025 +0000

    CA-414418: Detection of AD account removal does not cause logout
    
    For performance, during revalidate existing sessions, xapi query
    subject details from xapi db first, if the subject is suspend,
    then goes to AD, to make sure unblocked user can login.
    
    There is a backend thread to update xapi db subject information
    from AD. However, it can not handle the case that the subject
    is removed. (and should not remove the subject for user until
    user remove it explictly). Thus, the subject information is not
    updated and keep alive.
    
    In this case, subject revalidate always got session not suspend
    from xapi db.
    
    The issue is fixed by query subject information from AD direclty,
    and session revalidate thread handle the removed subject properly
    to kick off the sessions
    
    For performance, there is a follow up commit to resovle that
    
    Signed-off-by: Lin Liu <[email protected]>
    ```

[edwintorok]

Are you sure this solves the original bug?
AFAICT the initial query with 'cache:true' found that the account is missing (suspended), and the 2nd query with 'cache:false' said that it is not suspended (so I was guessing that winbind might also be caching something), but I may have misinterpreted the logs.

[liulinC]

No, the initial query with cache:true will always succeed and found the account not suspended.
(As xapi db update thread never update it due to NOT_FOUND exception)
The update db thread can not handle it, refer to my comments in the CA ticket.
And I verified it can resolve the issue.

[minglumlu]

I think the perf improvement is great!

[lindig]

Looking from the outside it seems like we are adding a cache for authentication results. But would it not be better to add this cache on a lower level to minimise changes for client code?

[liulinC]

Looking from the outside it seems like we are adding a cache for authentication results. But would it not be better to add this cache on a lower level to minimise changes for client code?

This is not exposed client API. so, no client code update is required.