For the past 2 years we have created 3 desktop application and 2 admin section(web) for one of my client.
Every application uses its own authentication process.
I have merged the authentication process for web in single unit.
But the client wants to have one screen for getting authenticated on desktop application as well as on website.
he also want to use different browser and the username /password should be asked only once irrespective of browser opend.
I tried to use cookies for web. but every browser has got its own cookies.
Can any one suggest how can i authenticate a user for the whole computer so that authentication information is available to desktop application as well as to website irrespective of the browser being used?
Edit: As suggested by joe using windows authentication is not possible in my case.
So i created one more table with following column
ip,userid,authenticatedat
when ever a user is authenticated i insert its ip,userid, and time in table.
when ever a non authenticate user comes first i look in the table if the ip is present and authenticatedat is within 30 min i assume user is authenticated and set the session/variable with data required.
This i have checked and found it is working .
I have found this is not secure.
Windows authentication is the only way I know of doing this. Assuming your users are on a domain you control, then their Windows credentials would validate them, and they wouldn't ever need to enter a username and password.
Outside of that, I can only think of hacky dirty methods of making this happen. You could install a single authentication service on their machine which is available to connect to remotely from other applications - those apps would call your service, and that service would authenticate the user and pass an authentication token back. Easy enough for Windows apps, but making that work on a web app wouldn't be fun. Your web server wouldn't be able to talk to this service, so you'd have to rely on the client javascript talking to the service and retrieving a token or hash, and then the javascript passing this on to the web server.
Anything you put on a local machine, you have to assume the user can reverse engineer and manipulate, so if you need real security, I doubt you'll find a solution. Best bet is just to make the user log in every time you need to, and have your authentication/authorization code on your web service layer.
Related
We have an MVC application that validates windows users by instantiating a principalcontext, locally and for domain users. However, this immediately fails when a connection to the domain cannot be made. Is there a way to leverage the capability of windows to still validate domain credentials when disconnected from the domain?
We see that in SSMS you can also use windows authentication after the server has lost access to the domain.
To be clear, the machine is joined to the domain but does not have access to the domain controller, i.e. a corporate laptop that is taken home.
Thanks for the help in advance.
The answer is in how Kerberos (and I believe NTLM is similar) works in that they use session tickets. So once authentication is successful against a domain controller, you have a "ticket" that proves you authenticated. When you authenticate to anything else that requires Windows authentication, the ticket is sent.
To take advantage of this, you must use the built-in Windows authentication. You cannot take a username and password and try to authenticate them that way.
If everyone who uses your website can use Windows authentication - then you can enable it for your whole site.
If you have a mixed audience - some who have a domain account and some that don't - it's a little trickier, but still doable. I've done it. You can look at the OWIN-MixedAuth project. I haven't used that specifically.
That project seems to use a separate button for the Windows authentication. When I did it, I made it seamless (it tries Windows auth and fails back to a login page). I did that by doing an AJAX request in the background to a page that requires Windows authentication, and if it succeeds, just forward on. If it fails, show the login fields.
All that said, I don't know it will work if the server cannot reach the domain. It will probably work for users who have already authenticated to the site before it lost connection to the domain, or if the site is hosted on the same computer that it is being accessed from. But it might not work if a user it has never seen before tries to login while there is no access to the domain. You will have to test.
But the benefit of using Windows authentication anyway is that you can make the login seamless. As long as the site is in your Trusted Sites (in the Windows Internet Options) then IE and Chrome will automatically send the user's credentials.
While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?
You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.
I have a scheduled task to create to get data from a site using the webclient
class. How do I execute a database update with the data retrieved under a different windows user? I was told not to use the same account to access the site as performs the update. Should I just create a windows service that runs the web request then call a db component with authentication settings set under IIS to run under a different user? Or is there a tidier way to do this running a single exe as a scheduled task? The Scheduled task runs under a single user. Could I run the task and switch user for the update? We are using Windows authentication at the database level.
Run two Windows Services. One to get the data from the website, running under Account "A" which stores the data locally. The other Windows Service running under Account "B" picks up the locally stored data and executes the database update.
Other designs will require you to store the credentials somewhere in a config or other file - this way the Windows Services are always running under the correct account for the task they are attempting.
You clearly stated that you will have to use a Windows user to get access to the database. However, often this will not be the case when you authenticate against a web site so exactly how you solve your problem will depend on the details of that.
You should probably execute your process as the Windows user that has access to the database. Then you have to solve how to authenticate against the web site. If the site uses forms based authentication it is a bit complicated but there is an answer to the question WebClient accessing page with credentials that might help.
If you need to use the WebClient.Credentials property to authenticate against the web site you might find it easier to execute your process as the user that has access to the web site. You then need to use impersonation to access the database. A simple way to do that is to use the SimpleImpersonation NuGet package.
In most cases you will have to store the password for one of the users so your process can use it to either log in to the web site or impersonate the user. A relatively safe way to store the password is to use the Windows Data Protection API (DPAPI). The class ProtectedData can assist you in storing secrets so only a specific user on the computer can access the secret (e.g. the password).
I'm working on a .net application that uses wsdl to connect to another service (the service is SpiraTest). I need to call authentication method in every request. The problem is that the service only provides a method to authenticate with a username and a plain-text password.
What would be a good way to save the username and plain password? I'm considering putting them in a session if I don't better options?
Users log in with the credentials to use the app and I use the same credentials to contact the remote service. User log on only once, but every time they navigate through pages that need data from remote service, I need to authenticate using the credentials that user gave when logging in.
Session consume more memory in server side and it is not good solution for your Task. What I suugest that Form authentication in asp.net. It create a cookie based on the credentials you have passed for authentication and it will be kept on browser until you log off from your App
http://www.codeproject.com/Articles/13872/Form-authentication-and-authorization-in-ASP-NET
I hope it may solve your problem
I'm not familiar with ASP.NET sessions, but I'm assuming they're similar to PHP sessions. In that case, the actual session data is kept in a file on the server. If you're just trying to keep your users from seeing this password, I think that keeping them in the session would be sufficient.
However, you haven't told us exactly how this username and password come to exist and are used. If you have just one username / password that your application uses to make requests to the web service, there is no point in keeping them in the session at all - simply store them in a global config.
I’ve been asked to integrate a windows form application with SagePay to take payments directly from the application. The SagePay documentation talks about ASP.NET so I’m not sure whether this is possible. Has anyone integrated a WinForm application with SagePay before? Is it possible?
I know some payment processors have a connection option where the payment part is hosted on a form on their server. You could try embedding a web browser control into your app to display the payment page.
Usually there is another type of connection option where you can send your information via HttpWebRequest, but I'm not sure that this would work as it requires SSL. Since you are running your app as a desktop client, I'm not sure what you would have available.
I am not sure this is possible given that sagepay needs to redirect users to Mastercard securecode or Verified by Visa, I think they would need to redirect to the bank which then redirects back to a supplied URL. I would think this needs to be within a browser environment.
You can post to urls and get back a response via .net objects and parse the results to display on a form.
You can also ask SagePay to create a Vendor account with 3d secure switched off. This allows you to take payments in house in your winforms app without the customers password however most card vendors if you bypass 3d secure will not protect you if someone calls and uses a card fraudulently.
However it can definitely be done.
You can normally post to secure servers from non secure pages so again this isn't usually an issue.