I've got a C# MVC application using Identity. I'm trying to find a solution to authenticate a Kiosk User:
normal users login using their credentials; be it local, FB, Google etc, from their home computer, phone or whatever
a particular computer however needs to be always logged in - even after the web server/application rebooted, the kiosk computer restarted etc. (well, at least after the server/kiosk computer is back and the kiosk computer returns to the application website, the computer needs to be logged in as that kiosk user again)
My simplest idea was to create a user role Kiosk that would be disallowed from logging out; however that doesn't solve the login problem unless I "remember" the kiosk user by a crazy-long-expiry-date cookie.
It also doesn't necessarily stop anyone from simply deleting the cookie (although I could live with that, the kiosk computer is in a monitored environment).
Identification by IP is not possible.
I'm looking for ideas on how I might be able to accomplish this. What pieces of software, or a certificate, or something could I install on that computer that'd allow me to check it is that one in my application?
Thanks for any suggestion that you might have.
This is commonly done with a persistent cookie as you describe, in the case of a web app. You could set the login cookie expiration to some long term date such as 1 year, 5 years or whatever makes sense. You can do this based on a role the user is a member of, user name, or some other identifier. I have done this before and I usually add a new option of some kind to hide the logout button/menu option.
Other options would be:
Client Certificate based authentication with IIS
Window Authentication if the machine is an AD member.
Special URL that is kiosk specific that signs the user in from a link/bookmark/button/whatever (this might just be a variation of the long term cookie option bypassing the password login)
Related
I'm trying to set up a web application so that it handles permissions based on the device being used to open the application. For example, any users who logged on to Device A can access www.example.com/Site/1, and any users who logged on to Device B can access www.example.com/Site/2.
But, all users have to log on to the device, so it seems that the cookie needs to be created for each user who logged on a device.
Is it even possible to share a cookie between multiple users as long as they are logged on to the same device?? I've been searching but I just can't find any information on this.
Cookies are set on a per-user basis only. If they were not, it would have been a major security breach.
Therefore, the answer to the question "Can one cookie be shared..." is NO.
A cookie jar is unique per browser + physical machine + user profile.
On a PC, there can be several user profiles, one per user. So users in this situation would have separate cookie jars and therefore cannot share cookies.
On a phone, there is usually no notion of separate user profiles (when you unlock a phone you don't tell it who you are, it just assumes you are the one and only owner). So in this case, there is only one cookie jar, and anyone who picks up the device and uses it will use the same set of cookies.
A tablet may be different. If the user has to sign on to use the tablet, and in so doing provides a unique user name, it is likely they will also have an independent cookie jar and therefore cannot share cookies. If they do not sign on to use the tablet, they are probably all using the same cookies.
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
I am implementing a C# MVC 4 application hosted in IIS 7.5 to replace the company intranet. The requirement is that when a user is at their personal workstation logged in with their windows credentials they will not be prompted to login(this is not optional the customer is firm on this as they believe this is how SharePoint works. Though I cannot confirm), however when they are on a mobile device or on a personal computer off the local network they will be promoted for their credentials. Also, while off the network the user should be able to log out, and the application should log out automatically after a period of inactivity. All users who have access to the application will have AD credentials.
I attempted to get a working solution with windows authentication, but it is my understanding that windows authentication is not intended for use outside a local network. Even if I could get the desired authentication results with this option there is no ability to log out without a significant amount of kludge and hacking with JS.
It appears that by default forms authentication is the answer, but is there a way to utilize the users windows credentials and authenticate against active directory with those without prompting the user to login while on the network?
Unfortunately even after I called Microsoft I was unable to find a good work around for this issue. They did suggest Active Directory Federation Service. This was not an option for us.
There is also a great blog post that does the opposite of what I am looking for but could probably be manipulated to work.
After working with my product owner we settled on a true forms authentication model. The way I was able to appease them was for users on the local network I am setting the time out for the forms authentication token and cookie to a longer duration and refreshing the duration so that if users are active on the application often enough they may never be prompted to log in.
This may not be the most elegant solution, but it has allowed us to meet the requirements set by the product owner. If anyone has additional suggestions I would love to hear them.
So we have an interesting problem at work that has cropped up and I know other companies have had this issue. Basically what it boils down to is, we ship a laptop to a user that works off VPN only (think like a contractor.) They use domain logons and pre-login VPN connections (all windows clients.) This all works fine, however, there are instances where the user cannot connect to VPN and cannot log in with their cached account, so the solution is to have them log in with a local account. Catch is, these passwords need to rotate in some fashion and we aren't going to give them the local admin password. So I am looking for a product, or a good place to start coding.
The Idea:
A button that is available pre-login. When this button is clicked, it generates a user that is an administrator (or we use a pre-configured user) and provides a number. They then relay this number to our helpdesk who enters it in a webapp or console app, it spits out the password the button just generated and is relayed back to the user so they can login with the account and the helpdesk walks them through troubleshooting. So is there a product that will do this?
The Code:
If no product exists, what do you think the best method for generating the one time password would be? The backend is simple enough, user creation/modification, helpdesk tool, etc. What I'm curious about is, is it better to start trying to stack onto the gina.dll and the button thing like in the idea or just create a service that is interactive with the desktop and is waiting for a key sequence to be pressed, like ctrl+alt+backspace+f12? Of course the service would be on a timer, after say 4 hours, reset that user password and force a logoff if it's logged in. Would most likely write this in C#, C++ if required for lower-level hooks.
Right now we have AD/Exchange to manage all of our users logins/e-mail on-site at the office. The major app that everyone uses maintains its own login accounts and all users have a tendency to forget login information for at least one of the two logins.
What I'm considering doing is using AD to authenticate the user in the application so that they don't even have to login to the app after they've logged into their machine.
The problem is that there are small number of users that work off-site (the app can work over the internet) and just use the machine's local account (which is causing problems of its own).
What I'm wondering is, will using AD to authenticate users on-site still be an option if a user works off-site?
The answer to almost any question posed to a programmer is "Yes..." It's what comes after the ellipses that is important. You may not want to do the things that come after the ellipses.
Based on the information in your question I think the answer is "No" but there are several scenarios where we could change that to a "yes".
If the AD account is only being used to authenticate that a user knows the password, then you could make a web service, host it in your domain, set it up to use windows authentication and SSL, modify the application to prompt the user for credentials, and call a method in the web service using those credentials. In that scenario, a successful call to the web service means that the user is authenticated. You could use the user's credentials to continue from there.
Detecting weather the application needs to prompt the user for credentials or not could be done by attempting to call the web service with the user's logged in credentials first. If this call fails then you know you need to prompt the user.
Not knowing the rest of the details of your application however means that there are many scenarios where this would not be enough.
I have done something very similar to what I described above. My scenario was the reverse: the application worked over the internet but I wanted it to be easier to log in in the cases where the machine has domain membership.
As an aside, the members who work from home: are they using laptops that are part of the domain or are they using machines that are not connected? In this case you may be able to use cached credentials but you should ask that question over at ServerFault.
Yes, you can definitely do that. It'll be a bit of work though.
What your app would have to do is either find out automagically whether it's directly connected to the office LAN, or working away from the office. Or you could have the user tell you, of course :-)
If it's on the LAN, no problem - you authenticate against AD.
If it's away from the office, you could e.g. call a WCF service on the company LAN, pass your Windows credentials, and have it authenticate you against the company AD. If you provide the right set of credentials, you'll be authenticated and allowed to work - if you're not allowed to log in, the call to the WCF service would fail.
You could do this almost automatically by using Windows credentials - in which case the "remote" user would still have to log on to your domain and use his / her normal Windows credentials; or you can pass username/password over the wire to WCF, or even install a certificate on the remote user's machine that WCF will then map to an AD account on the server side.
The options are plentiful! :-)
Marc