I have software that is serving up hundreds of different websites on different URLs via HTTP. However, we are now adding functionality so that users can login and do various other tasks, however this needs to be run via HTTPS, so we've run into a little problem where the user needs to be known on both websites, but we obviously can't set cookies across domains and can only see user credentials via the HTTPS domain. I'm trying to discover the best way to forward credentials onto the HTTPS site for login, but also let the primary domain that the user has logged in.
Related
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.
Scenario: I am creating an application which uses OAuth for authentication and I want to try and limit a user sharing their credentials with colleagues (we charge per seat). The only way I could think of this was to store the IP with the token (although I'm aware multiple users from a single client could be on the same IP).
Is there a standard way of doing this in OAuth?
Not via any feature specific to OAuth. A valid user that logs on from the office or from home will have a different IP address. How would you distinguish that from another user that has someone else their credentials?
The only way I see to make this work is require two-factor authentication. It's much less likely your users will be prepared to share for example their phone to use your application.
Just make sure your application adds enough value that your users will want their own account and not share credentials.
Our client requested from us to make our web application accessible from Intranet and Internet.
When user tried to access the website from Intranet, The user should be logged in immediately (Windows Auth) ... The user should have public access also (e.g. Home, Coffee shop), But in this case he should use his credentials and the server will check if its valid.
Any advises?
This is the standard way Integrated Windows Authentication works. If you're inside the intranet (logged onto the domain), IE will automatically send your credentials when the website returns 401.2 (no auth method specified). When you're not inside the domain, the credentials will have to be prompted for, since the domain server cannot be contacted from the client machine.
This is not the same as the "tricky" solution you referred to. That solution is tricky because it also uses forms authentication, which you don't need here (AFAIK).
We decided not to use Windows Auth at all.
The customer want to stay logged in if he is in the Intranet.
so we did the following (and the customer is ok with that)
Forms Auth + 'Keeps me logged in' checkbox
Validate Credentials with AD.
Check if User in trusted IP Addresses Range (Something like allowed IP addresses in SQL Azure)
If trusted IP Range, user becomes authenticated.
If its not, Two factor auth by sending SMS.
One more reason for not using Windows Auth.
The user want to log-out at anytime to use different credentials to do some special tasks.
Usually customers do not know what exactly they want, so we will start dreaming and make things complicated. 'Simply keeps me logged in' for trusted IP addresses and he will stay logged in for N days.
how can I synchronize sessionID over multiple second-domain servers? For example, I've got servers(you can log-in into server swarm at any of these), www.service1.com, www.service2.com, www.service3.com, and if you log in at one of them, the login information (+anything else) should persist along them. How can I provide SessionID to other domains? (session itself is stored on sql server shared across the services).
Cross domain logins are possible, but very tricky, and prone to issues.
Generally a scheme to do this will involve a third server that acts a centralized auth server. Login requests on individual sites will route through the auth server and the auth server will pass back a secure token to use as a session id.
I've seen this session id passed back to the server via url redirects, and also through back end server communication.
My personal advice would be to use the auth server as a webservice of some sort, and maintain individual sites logins separately. The workflow would be roughly:
Sign in on a given site
The site would send a behind the scenes request to the auth server asking for authentication and information
The auth server would respond appropriately
The site would login on success, and show error message on failure.
It is possible to use some fancy redirects and some forms of trust to implement a auto login system, but honestly such things are rarely if ever worth it. The above suggestion would end up with them having to login on each individual site, but they'd share the same credentials and profile on every site.
Don't you mean across domains?
This is not possible due to security features in browsers. Browsers do not allow cookies to be accessed across domains.
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