Login an account without password

Hi, We have a need to be able to login a user account without having the users password in an “activate account process” (ie. click a link to activate your account).

The Litium Api doesn’t natively support that (it seem to always need username + password). But we’ve tried to replicate what Litium does in the background of the regular login. However it doesn’t seem to work 100% of the times, so if someone could have a quick look at code we run and say if something is missing?

var principal = new ClaimsPrincipal(securityContextService.CreateClaimsIdentity(account.UserName, account.LitiumSystemId));
principalContextService.SetCurrentPrincipal(principal);
if (authorizationService.HasOperation(Operations.Function.Customers.Content) ||
    authorizationService.HasOperation(Operations.Function.Sales.Content))
{
    auditService.CreateReadEntry<AuthenticationService>(Guid.Empty);
}

eventBroker.Publish(EventScope.Context, new PersonSignedIn(account.LitiumSystemId));

Account is our account class wrapper, but should make sense what we’re trying to do

Litium version: 6.1.2-patch-1806080803

The question is not very clear.
Normal scenario of “Activating account” is a link sent over e-mail when the user register for an account, then the account is created in a de-activated state.
When the user click the link, the account is switched to activated, and user is redirected to login page to put in his user name and password.
If the account is auto generated, then the temporary password is sent to the user with a seperate email.
So, the “Activate account” normally does not loggin the user in automatically due to obvious security reasons, and better practice is to ask the user to put in the password again.

Anusha, I’m sorry to say that I disagree. Both in terms of normal scenario (without having any detailed statistics) I feel it is more normal to be logged in automatically when you click an activation link. I also disagree that there is “obvious security reasons” with doing it that way. Only way that is a security risk is if an attacker has control of the users mailbox and if so, the attacker could just use the reset password functionality to set a password.

Temporary passwords are also a thing of the past (The user often forgets to change temporary passwords, and sending passwords over email is never a good thing), it’s more common to use a “reset password”-link where the user can set a new password. (This is what we are using).

Also, It’s important to weigh usability vs. security when it comes to sign up. Signing up is something the users tries their best to avoid, so it’s important to try to make it as frictionless as possible.

Ok, have you seen the code here:
https://docs.litium.com/documentation/architecture/external-login-providers

Though it is not directly what you are searching for, this is how a external login provider is used to login to Litium. Perhaps you can get some insights there.

If you try to call the AuthenticationService.RefreshSignIn() before the event publisher. The RefreshSignin will set the autentication cookies for the current principal again.

Complete code something like this

var principal = new ClaimsPrincipal(securityContextService.CreateClaimsIdentity(account.UserName, account.LitiumSystemId));
principalContextService.SetCurrentPrincipal(principal);
if (authorizationService.HasOperation(Operations.Function.Customers.Content) ||
    authorizationService.HasOperation(Operations.Function.Sales.Content))
{
    auditService.CreateReadEntry<AuthenticationService>(Guid.Empty);
}
_authenticationService.RefreshSignIn()
eventBroker.Publish(EventScope.Context, new PersonSignedIn(account.LitiumSystemId));