Auto-login does not take --resume and --alt into account

[LennardF1989]

Hello,

I want to use the SDK to automate some administrative tasks. One thing I'm playing with is to allow users to request access to shared folders through an internal web portal. My support team should then be able audit the request and provide access with the press of a button.

Obviously, security for Keeper is tight and you need to jump through some hoops to talk to the API. In order to do the above, I need some sort of persistent login, otherwise my support team will constantly have to re-login the web application, and that kind of defeats the point of the whole idea.

So, in order to achieve persistent login:

• I need an account with a Master Password, assuming (and please correct):
  • SSO login does not work, since you have to go through the challenge every time?
  • No 2FA enabled, or 2FA enabled but with duration set to forever*?
    • * Or rather hacky, but the web app itself can generate the 2FA code when required.
    • But what would the recommended approach be for this? I'm contemplating setting up the Vault once, then lock down all access except Commander, but I still don't want to make it too easy for anyone with the credentials to gain access, obviously...
• I do the login using the Commander once to setup the config.json
• After that, I keep my session alive by connecting to Keeper every 12 hours.
  • This is based on https://github.com/Keeper-Security/keeper-sdk-examples/tree/main/AzureAdminAutoApprove - but where can I set the timeout delay, is that an account setting?

Thanks!

[sk-keeper]

1. Persistent login can be used with any account type Master Password or SSO
2. Yes, 2FA duration should be set to "forever" unless it is OK to re-login every 30 days
3. Persistent login can be disabled in enterprise environment
4. Yes, config.json file can be setup with .Net Commander. There are 2 Commanders: .Net and Python. They have incompatible config.json file formats. Please use the latest .Net Commander build. https://github.com/Keeper-Security/keeper-sdk-dotnet/releases/tag/v1.0.5-beta07 It has persistent login bug fixed.
5. this-device command shows persistent login status for the account.

   
   My Vault> this-device
        Device Name: Commander C#
     Client Version: Commander 16.5.0
   Data Key Present: True
    IP Auto Approve: False
   Persistent Login: True
     Logout Timeout: 1 hour(s)
    Biometric Login: False

Available sub-commands: rename, register, persistent_login, ip_disable_auto_approve, timeout, bio

It shows that persistent login is enabled for the account.
Logout timeout is 1 hour.
`this-device persistent_login on` enables persistent login feature for an account
`this-device register` sets up persistent for device (or config.json)
`this-device timeout 1440` sets logout timeout (in minutes) to 1 day (it is enough to connecting every 12 hours)
Only one device can use persistent login feature. Any attempt to login from the another device automatically cancels existing persistent login connection.

[LennardF1989]

Please use the latest .Net Commander build. https://github.com/Keeper-Security/keeper-sdk-dotnet/releases/tag/v1.0.5-beta07 It has persistent login bug fixed.

I'm running of master, did the commands, this-device shows things as I want them, but every time I restart the Commander, it will ask for a SSO token.

How can I check if my enterprise has persistent login disabled? When I go into the vault I can freely check/uncheck "Remain logged in", the only thing that's required is the logout timer (which has a maximum of 480 minutes, so 8 hours),

[LennardF1989]

Okay, apparently _auth.ResumeSession has to be set to true in Commander through LoginOptions, then it works.

So, just to be sure, ResumeSession = true, if used within the Timeout window, will keep the account logged in indefinitely?

[LennardF1989]

@sk-keeper A workaround to start properly is to set last_login to username@tld.com --resume --alt in the config.json for example, but it only works once, because after exiting the config.json is updated again without these parameters.

I would like to propose to also persist ResumeSession and AlternatePassword in the config.json, so that information can be used when the login command is queued in NotConnectedCommands.

Right now there appears to be no way to start Commander and resume an old session other than canceling to auto-queued login command, and then redo it with the right commands Doesn't work, because the session will get revoked and you will have to re-login.

EDIT: My current fix is in StoreConfigurationIfChangedV3 in LoginV3Extensions:

var lastLoginArray = new List<string>
{
    auth.Username
};

if (auth.AlternatePassword)
{
    lastLoginArray.Add("--alt");
}

if (auth.ResumeSession)
{
    lastLoginArray.Add("--resume");
}

var lastLogin = string.Join(" ", lastLoginArray);

if (string.CompareOrdinal(auth.Storage.LastLogin ?? "", lastLogin) != 0)
{
    auth.Storage.LastLogin = lastLogin;
}

How the above would then work is that the first time you login you pass the right arguments along (eg. --resume) and it will be persisted for future runs.

To break out of the last-login cycle is to type cancel, then username@tld.com --resume --alt, fill out the information and type q to quit. Next time you run Commander, it will pass --resume --alt to the argument parser, and resume the session properly.

I renamed this issue accordingly.

[sk-keeper]

So, just to be sure, ResumeSession = true, if used within the Timeout window, will keep the account logged in indefinitely?

Yes, that is correct

[sk-keeper]

Sorry. The latest changes in release_1.0.5_beta07 branch was not been pushed to master branch. https://github.com/Keeper-Security/keeper-sdk-dotnet/commit/a6003b81ad6db2d370a8e0ffa3f4f42b30674053

Thank you for pointing it out.