1

Essentially I have a application that is 2 parts.

  1. One part is on the user's machine, which will upload files to my server, and

  2. the other part is a web application that works with those files.


Both of the Applications implement security protocols for Authentication/Authorization on their own using the same security framework, but I'm not sure if they actually share any Session data (not sure how I would find that out).


My question is.... if I added a WebView portion to the Main Application, would it be wise to make them log in again, since that's default functionality when going to the site?

Or, since they already logged in the main application, that there is no point in making them "log in again?"

To add further into the discussion, the Main Application is more of an admin control area, where you create your users, so that others can log in to those users on the web.

IF I were to have 1 login for both, would it be weird logging into the admin (main) and then wanting to view a user would log in itself through the main Application and forcing a login?

I figured I would post both scenarios, in case one would be different.


I assume that once you are in, it doesn't matter what happens. The user accounts cannot be edited from the web, just the main application, so in reality once you are logged into the main, there isn't much you could do by auto-logging into the web part.


I also am curious if I were to implement a password recovery for users, if it would make sense to allow changes to passwords in the application (without remembering the user password), or do a recovery process as if they were the admin. AS I said above, once you're logged into the Admin, all users are vulnerable to anything.


Thanks for any advice!

3

I'll propose a rule of thumb which may help you with your decision:

When switching from a lower privilege level to higher, make them login again.
When switching from higher to lower, do not require another login.

Here's an example of how bank ATMs implement this rule. Consider these 2 scenarios:

  1. You put in your ATM card, enter your pin, select "Withdrawal", choose your amount, receive your money, view the balance of an account.
  2. You put in your ATM card, enter your pin, view the balance of an account, select "Withdrawal", choose your amount, enter your pin again, and receive your money.

The only difference between these scenarios is whether the withdrawal happens before or after the balance inquiry. If you begin your session with a withdrawal you are assigned the highest permissions, and therefore you can do an item of lessor permission afterwards. If you begin your session with a balance inquiry, you are assigned lower permissions, and then in order to perform a withdrawal (which requires the highest permissions) you must enter in your pin again.

Perhaps you can use similar reasoning when determining if your user should have to login again.

  • Thanks for this, it made a lot of sense, and echoed what I believed. Which is that since it's going from Admin to User, then it shouldn't be an issue. I was also curious what you think about my password question? Now I make it so that a recovery is sent to the email on file for the admin, so the admin controls all passwords, so if I allow them to change user passwords, without knowing it, would that be an issue? He could technically delete the account, make a new one, etc, if he didn't know the password, and didn't have access to the email on file, but maybe del should be pass protected. – XaolingBao Apr 28 '16 at 22:48
  • Also, I didn't realize ATMS make you re-enter pins for withdrawals. I don't use ATMs much, but interesting information. – XaolingBao Apr 28 '16 at 22:51
  • Typically once you're an admin you have full control so allowing admins to change passwords is probably ok. However, if a password needs to be emailed to a user, then it's best to provide a reset link/token and let the user change the password themselves. In that case admins can initiate password resets, but would never actually know other user's passwords. – TTT Apr 28 '16 at 22:59
  • Thanks for the info. In my case the admin creates user accounts and allows others access to the accounts. The users don't really have much control, the admin is what controls everything. I figured since he sets the passwords, and gives them out, that if he forgot one, instead of a reset token, it would be just reset within the application. From your analogy it seems that would be okay since he;s the admin, and controls the passwords anyways. – XaolingBao Apr 28 '16 at 23:30
0

You open yourself up to bad user behavior at that point. Really you want to keep them safe by making sure you protect against as much bad user behavior as possible.

If an admin opens the web view it makes it easier for them to forget they are in the admin area and leave without signing out of the admin area, leaving it open to someone sitting down and gaining complete control.

Of course this is a bad user scenario and akin to the admin walking away with the admin app open, and how do you really protect against that? The only thing they gain from being forced to log in again is that you can at least log them out of the admin app and try to keep them safe, but you can do that anyways with timeouts.

So really Admin to web view is fine since you're going from Elevated to User, but you should log them out eventually in either case.

  • 1
    Thanks. Essentially the user part would be within the main application, so if they somehow forgot they were in the admin part, then that's a big problem, and that could happen at any point in the application, imo. Also, to fight against that would be session timeouts and such, so that even uif they "forgot" which is highly doubtful, then it will log them out themselves. – XaolingBao Apr 28 '16 at 21:54
  • Which is what should be used in that place. The only thing that kind of scares me is a shared session with a single point of authentication. If they log into the web view, do they have to log into the admin view even if the sessions are shared? – Robert Mennell Apr 28 '16 at 21:59
  • The user and admin loginss are separate. They don't share a session, that was just an idea, which I'm not fully sure how to implement in this case, but I might be able to figure out. The admin would not give out his credentials to the user, and the user wouldn't be able to get the application in order ot login. I am trying to separate it so that admins can only log into their respective application, and users in the web part. – XaolingBao Apr 28 '16 at 22:06
  • So esssentially the Admin App would have a tab with a WebView component that would allow access to the User's area with or without entering the password. The Web portion wont have access to the main, and most users will never have access to the main, and even if they somehow did, their passwords would not work. – XaolingBao Apr 28 '16 at 22:08
  • Going from the Admin app to the web view and not logging them in is fine as long as you can try to prevent the bad user behavior(which you already mentioned you plan too) – Robert Mennell Apr 28 '16 at 22:10
0

I've seen several web applications that implement a "sudo mode". In your example, it might look something like this:

I, an admin, am logged into your application, and stay logged in for long periods of time (perhaps the session expires after 30 days). I protect this account with reasonable amount of security, but I'm not super paranoid about it.

When I want to do something admin-y, I get a page that prompts me for my password again. I enter it, and then continue on my way. After 15 minutes of inactivity (i.e. no requests with my session), the sudo mode expires and admin actions once again require a password prompt.

This setup is slightly annoying for the user, but it's not too bad, as you can batch a bunch of admin operations together without re-entering a password each time. And providing a separation like this is useful any time a user account is primarily used for pretty mundane stuff, but can be used for important/sensitive actions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.