I have a MVC3 mobile intranet site targeted, among others, towards tablet devices (iPad).
When I open the site on an iPad, I get a pop-up screen asking for logon credentials. I cannot in any way cache these credentials, so every time this application is opened the user is prompted for their credentials.
Since it's not possible to include an iPad in a Windows Domain (as far as I know), is there any way at all to get a login screen using Windows Authentication, making it possible to cache credentials and maybe maintain the session over longer periods of time so that the user will not have to re-enter their credentials when opening the site ?
It's definitely possible as that's what Exchange OWA does. These articles may be of use: http://helios.ca/2009/05/04/aspnet-mvc-forms-authentication-with-active-directory/ & http://msdn.microsoft.com/en-us/library/ff650308.aspx
Once authenticated via the form you can just add a session/cookie to maintain the session.
Related
We have an application which has two user types. One of them is an administrator and the other one is a client. We are using AspNet identity to authenticate the user and issue a cookie.
However, there is a scenario where the administrator and the user share the same browser. When the client logs in, the cookie gets overridden and when coming back to the administrator pages we lose authentication. The same happens the other way around (client is logged in first, then admin).
Is there a way to support multiple authenticated users at the same time on the same browser?
Greetings.
Luis.
No, the browser has no understanding of any users. You set cookies and the browser sends back those cookies. The application then receives and checks those cookies to figure out the current user on the next request;
There's no way for the browser to know what cookies it should send back and there's no way for your server to know what the right user is other than reading those cookies. Why do you want 2 different user types sharing the same exact browser window anyway? That defeats the entire security model.
If 2 people must share the same device, then most browsers today support private windows or separate 'profiles' so you can have completely separate preferences and sessions without sharing any data. Here's a link to Chrome's profiles feature: https://support.google.com/chrome/answer/2364824
On my Intranet Web Application, I have enabled Windows Authentication. For the first time when I take the App, it asks for Windows Authentication. From there it will never ask. How can I know whether the authentication is happening on each refresh of my page after first attempt?
For example, if I tried to change my Windows password while the app is running, will the app prompt for password again on refresh?
The authentication happens when you first connect. The server knows who the user is and is able to keep them logged in. If the user changes the password it will not ask them to re-authenticate until they close out the browser. This is due to the fact they already have an authentication and that will stay there until their session is done, usually by closing all instances of a browser (multiple windows of the same browser can share the same memory for things like cookies and authentication)
Think of it this way. You go into your home after you unlock the front door. You don't have to do this again until you leave your home. You can change your lock while you are home and still be in your home without having to unlock it again until you come back.
I'm afraid I cannot get through this problem on my own. It is weird that this issue seems to be unique for my installation.
On my WordPress-based website users are having trouble with the login, especially when using their mobile phones to authenticate: they are being logged out (even when checking "Remember me") and will have to re-enter their credentials (after which they're logged out again). From what I figured, it is most likely the fact that their respective mobile Internet Service Providers dynamically assign new IP addresses to their devices all the time, causing the authentication to fail.
When I'm using my desktop to login, everything will work just fine. However, say, I have successfully logged in to the site with Google Chrome, and I open an instance of Mozilla Firefox (or any other browser) to log in simultaneously, Chrome's user "session" will be shut down immediately (I know that because an asynchronous script is requesting whether or not the user is logged in and it prompts me to log in once I sign in using the other browser). Therefore I believe that the whole WordPress authentication has got something to do with the user agent, too.
Albeit I highly appreciate the extra amount of security provided by automatically voiding a running session when accessing the site from a different IP or browser, my users do not. Even for myself it is remarkably cumbersome, using three different machines plus tablet and phone to access the site from any possible place (eventually I stopped bothering to log in and just waited to get home).
Since WordPress authentication uses cookies, I looked into how these are generated. The wp_generate_auth_cookie() method uses the user name, parts of their hashed password, the expiration time and a salt (a constant salt defined in wp-config.php), but neither does it use the IP address nor the user agent.
I literally searched the whole WordPress folder for "user agent" or "IP address" occurrences but there is no login-related script containing the terms (merely a handful of plugins that don't affect the user session at all).
That puzzles me. How does WordPress even realize that I am logged in with a different browser / computer if it doesn't store that data with the authentication cookie? And where does the check happen that logs me and my users out?
Do you have any further ideas on how to troubleshoot the issue?
Thank you very much in advance!!
Harti
Cookies are stored by browsers and different browsers on the same machine don't share that storage. Thus when you login with Chrome, WP sends a login cookie to Chrome, starting a new session. When you then access the site with Firefox, FF doesn't have a login cookie so WP prompts you to login and then sends a login cookie to FF, also starting a new session. The next time you access the site with Chrome, it gets Chrome's login cookie, which doesn't match the last one sent out that's associated with your username, so everything starts all over again.
This doesn't directly explain the problem with mobile devices; it sounds like for some reason they aren't storing the cookies properly.
Its not an original question. There is already a batch of articles describing this problem and solution for it. They all are dated back to times of .Net Framework 1.1 and IIS 6.0 and are not really helping with all the membership and role providers stuff we have nowadays. But lets get closer to the problem.
The problem is short.
You have an intranet site using Windows authentication and it works just fine. All you want is to give access to this site to users from their homes and to users who don`t have Windows based workstation.
Duplicate the whole site would be cumbersome because all the application except Login part would work well just if appropriate information would be saved in cookie on Login step.
You are welcome with any suggestions.
You don't say if internal users are authenticated or not, so, as it's an intranet I'm going to assume they are, via integrated authentication.
The simplest way would be to leave it as is, and turn on digest authentication if you are in a domain environment in addition to integrated authentication - this would prompt users not on the intranet with a username/password popup and they can login with their domain credentials.
If you don't have a domain - then how is it an intranet site? How are users authenticated? If you're in a workgroup scenario, where users have login details on their own box, and login details on the intranet server (in which case moving to AD would be better all round - no need to keep the passwords in sync, or deactivate user accounts in multiple places when people leave) then mixing Integrated authentication with Basic Authentication would do the same thing - however if you're going to use Basic Authentication then you will need to add an SSL certificate to the site to stop usernames and passswords being sniffed - Basic Authentication sends them in plain text.
Well, what you could consider is if you can use Active Directory, there is a provider to use the AD store for security, that would work for both.
HTH.
Is there a way to get the logged in user from a vb.net web application? IE, if someone logged in as "foo"/"bar" on their local machine accesses the site, I need code to get me "foo"/"bar". This is for a passthrough on our intranet, where everyone uses the same Active Directory.
Essentially, I need to harvest the username of the logged in user and check it against our ActiveDirectory instance. If that fails, I need to check for Request variables and check those (that part is fairly easy). Then if THAT fails, I need to show a login screen (I also have a handle on this).
I've already come across and discarded a couple solutions for the part I'm having trouble with:
request.serverVariables("LOGON_USER") - This only works if you have anonymous access turned off in IIS, and that must be on to use forms authentication (which I'm using).
http://www.thescarms.com/dotnet/IsInRole.aspx - This solution does not seem to work for some reason. I suspect the line AppDomain.CurrentDomain.SetPrincipalPolicy( Principal.PrincipalPolicy.WindowsPrincipal) is the issue, but the meaning of this line is buried so far I can't figure out what it's actually trying to do.
HttpRequest.LogonUserIdentity?
if you're using Forms Authentication, have you tried System.Web.HttpContext.Current.User.Identity.Name?
The web browser will not send the user's local credentials to the web server unless two things are true:
The web server asks for them (i.e. Anonymous Access is disabled, and Windows Integrated Authentication is enabled).
The web browser has been configured to send local credentials if asked (an Internet Explorer option, available in FireFox via plugin, not sure about other browsers). If the browser has not been configured to send the information and the web server asks, the user will be prompted within a pop-up login screen.