windows users vs. custom [closed]

Question

My application needs to support a "shift change" scenario. Essentially, a person is managing some assets. At the shift change, the person that was there leaves right as the replacement signs in. The assets can survive on their own for no more than three minutes. The server will re-assign the assets if they are neglected (which is not ideal). Currently, our application has a custom user system and supports a user fast-switch feature.

However, our primary customer wants to use Windows Domain users instead of our custom user system. He wants to tie our permission system to local machine user groups. It has the great advantage in that I can rip out a lot of questionable and insecure user management code, and I won't have to store passwords anymore. In my mind, that gives two options for the quick switch:

1. I can make our software (configurably) log off from windows on exit and auto-start when a user logs in. This has a disadvantage in that the assets are offscreen for some time period. It is easy, though.

2. I can keep some in-application logon form where I validate the Windows user and impersonate that user for my server requests. In a previous job I worked on a software package that took this approach. I always felt it was a bit weird having an application running as a different user than the desktop. There are some significant security concerns that go with this approach. I probably end up keeping the settings per Windows user, not per application user, etc.

Thoughts? Which path do you recommend and why? Is there some better way to do this that I didn't consider?

Answer 1

Of the two options you have listed, the best solution really depends on how this software is used.

If the software can only every be used on the specific computer(s) that it is installed on, then option 1 is fine, as it does everything you need, and if the user has any files related to their active directory windows login, they can also access those.

If the software is supposed to be more flexible, with the possibility of it being run remotely on non-domain computers, then option 2 provides that flexibility. This could, for example, happen if an employee needed to use the software on their home computer, allowing them to work from home.

If it's not clear where the software will be used, or both will be, consider implementing a hybrid approach where if an active directory permission is set, the user will be logged in automatically, but if this permission is not set, or the computer has not joined a domain, then it will require entering the credentials. The Outlook email client does this on windows.