Is there a way to override how the login to backoffice works? We want to add multi factor authentication only when logging in to backoffice.
I had an idea of just redirecting all calls to /Litium/UI/login and handle the login in like another controller. But I don’t seem to be able to do a redirect when there’s an internal redirect done to the login page. Like when you just type in /Litium.
Litium version: 7.6.2
It’s not possible to override the back office login. Only forcing usage of MFA in that login form will not help to protect the back office due to the fact that if you login on the public site you will also get the authorization for the back office if your user have that access role. To protecting the back office with MFA you need to force the MFA for the person account but the back office login form is not handle this type of redirection to be able to force the MFA.
Feel free to create a request on the idea-portal.
True, but the login on the public site can be controlled. E.g. blocking login for users with backoffice access forcing them to use a login with MFA. That was one of my ideas to solve that. My only problem is that I can’t seem to block the backoffice login page. I’ve managed to do a redirect if you go directly to the login page url. But as I mentioned, if you’re not logged in and go to for example /Litium or /Litium/UI you’re redirected to the backoffice login page and my redirect “hack” doesn’t pick that up so you end up on the login page anyway. Any idea on where that redirect happens and if I can take control over it somehow?
One way of redirecting from the backoffice login page is to put this in web.config.
<location path="Litium/UI/login">
<system.webServer>
<httpRedirect enabled="true" destination="/some-mfa-login-page" />
</system.webServer>
</location>
But that doesn’t pick up the redirects to Litium/UI/login mentioned above.
That’s the Angular application that is handling that URL and using the browsers History-api to update the visible URL in the location field. No request for the URL-change are sent to the server where your other “hack” applies.
I don’t know a direct path that you can do to override that behavior.
Using an external login provider works fine to login to the public site, but trying to access Litium backoffice after external login will redirect to the Litium backoffice login page where the user have to enter any credentials (does not need to be valid) to enter backoffice.
The reason for this is that the Litium backoffice Angular application has built in logic to automatically refresh current users token and set this in localStorage*, the refresh is done automatically if token is not valid. BUT, for the refresh to trigger at all the key oauth_token_id need to be defined in localStorage*.
So that is why any credentials work on the backoffice Login page after external login, it will set the key oauth_token_id in localStorage, triggering Litium to refresh it with a valid token value (if I am authenticated with the external provider) and I get logged in.
So to skip the additional backoffice login when using an external provider just add the snippet below to index.js - this will add the key to localStorage* if missing:
// For Litium to auto-refresh the token used in the angular application
// the key oauth_token_id need to be defined in local storage.
// When using external login this key is not automatically added, so add if missing:
if (!('oauth_token_id' in localStorage)) {
localStorage.setItem('oauth_token_id', null);
}
* to review browser localStorage, open Chrome devtools and select application-tab. There you can find it in the left menu Storage > Local storage
@marten Where am I supposed to find the index.js file? I can see that there is one in the accelerator in Client/Scripts, is that the one you mean? We’re not using the accelerator so we don’t have that.
Yes, that is the index.js i meant, but you can put the code anywhere (framework/loginpage/global js-file), as long as it triggered in browser at least once before the user is redirected to /litium.
OK, thanks. We’ll see if that will come in handy.
Our problem is that we only want to use multi factor authentication for backoffice login, but since there’s no way to stop people from accessing the backoffice page that doesn’t seem possible.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.