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.
Related
We have an ASP.NET/MVC website that's using FormsAuthentication. As is usual, when the user tries to access a page, and doesn't have a valid FormsAuthentication cookie, IIS redirects him to the login view. When the user does a HttpPost to the login controller, our controller action makes a call to our WebApi webservice, which validates username, password, and customerid against a Sql Server database. If the authentication passes, the controller action sets a FormsAuthentication cookie, and redirects to the page the user had asked for.
Now sales is making noises about "Single Sign-On", though I'm not clear exactly what they mean by that. From what I've read, in the Microsoft World this usually means accessing MS's Active Directory Federation Services.
At this point I have almost no idea how this would work, but before I dig into this too deeply, would it be possible to put the authentication code within the WebApi webservice, where we could choose to validate against the Sql Server database, or against whichever ADFS server was appropriate for the specified customer?
Our problem is that we have I don't know how many thousands of users, working for some hundreds of customers. Many customers will not have ADFS running, and those who do will each have their own ADFS server.
Most of what I see with respect to Single Sign-On seems to involve doing browser redirection to the ADFS server, then redirection back, and looks to be avoiding login at all, if you're already logged in. I don't think we can do that, in our case. We can't know which ADFS server to redirect to, until we hit the database.
So, the question - is it possible to do ADFS authentication entirely from C# code in our WebAPI web service?
(One possible complication - the website itself has zero access to any database. The sole configuration setting in its web.config is the base URL of the webservice. Whatever authentication happens has to happen in the webservice, not in the website.)
First of all, "Single Sign-On" (SSO) is not limited to ADFS. It simply means that you type your credentials only once, and then all systems you access automatically "recognize" you; all subsequent authorizations request are transparent. For instance, if you have several web sites using Windows Authentication in your company Intranet (same AD domain), you have SSO: you authenticate once when you log in to your computer, and then your web browser authenticates automatically to these web sites using NTLM or Kerberos. No ADFS in this case.
What ADFS (and "Federation" more generally) allows, is SSO accross security boundaries. In Windows world, a security zone is typically created by an Active Directory forest; everything within this forest is accessible using SSO provided by Windows authentication. But as soon as you leave this zone (SaaS application, web site in another company network), you need another authentication protocol to perform SSO, and these protocols are implemented in ADFS.
Then about your particular problem:
What you could do is instead of using FormsAuth, you use AdfsAuth. When a unknown user accesses a page, he would be redirected to ADFS for authentication (using browser redirects as you correctly mention). To know which ADFS server should authenticate your user, you need a way to differentiate them indeed: a list of IP range per customer? a different URL per customer? If you don't have something like this, then the only way is to show them a list of choices such as: "I work for CompanyA", "I work for CompanyB", "I work for CompanyC", "I don't work for any of these companies and want to authenticate using FormsAuth."
In this case, what your WebApi web service has to do is: if I know which ADFS server to use, redirect the user there. Otherwise authenticate the user as usual using the database.
When you use AdfsAuth for a customer, your database is useless. You can delete all credentials related to this customer.
do ADFS authentication entirely from C# code in our WebAPI
Well it's possible to "re-implement" ADFS in your service, but you won't get SSO if you do that. When you use federation, your redirect the user to the ADFS server of his company. This ADFS server is in the same domain as his computer, so the user gets SSO here. Once again, your users can't get SSO if you authenticate them yourself, because your users are not in the same security zone as your site.
When authenticating to multiple identity providers, it is typical redirect to your own STS. So, in this case, you would have www.yourapp.com redirecting to sts.yourapp.com, which redirects to sts.somecustomer.com.
The specific tools to enable such a dataflow is the home realm parameter (whr), and the AD FS Powershell API (to allow IDP maintenance).
Your RP-STS acts as the trust-point for the app, and manages selection of the appropriate IDP. One RP-STS, many IP-STS's. Each of your Customer's IP-STS gets set up as a Claims Provider Trust in AD FS.
As always, Vittorio has already covered the subject better than I could.
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.
So I'm working on a mobile web app using jQuery Mobile, and I need to request some data from a remote server from the app. I get the data either from a C# SOAP web service, or from an IHttpHandler that returns JSON. I need to somehow authenticate with the web service/handler before any data is returned. I was hoping to use ActiveDirectory, and somehow pass a user name and a hashed password to the server via an AJAX request. The problem is, examples of authenticating in C# with ActiveDirectory involve passing a plain-text user name and password to PrincipalContext.ValidateCredentials. Is there any way to securely pass credentials to the C# service and have it authenticate with AD, without it knowing the plain-text password?
Edit: thought maybe I could hash the password client-side, pass it to the server, let the server get the AD password for the requested user and hash it the same way, then compare, but getting the AD password isn't possible.
Edit: Looking at aSSL.
If you are developing a mobile web with jquery ui, it wont live on the device, it will live on your web server (iis, if its a web application). Your application can authenticate using windows authenticatin against the service it needs to query, however it depends on the user used to run the application / impersonation being used on ur side.
The question is how your application and this service communicate between themsleves and the internet. If the service is not accessible to the internet, i dont know how much you should worry about the transport being secure.
You also can check out ad fs / ad fs 2 based security solutions and wcf integration options, such as explained here, for example.
These solutions implement the concept you are talking about, with the AD FS being the service that authenticates/ validates the credentials passed, and returns a token to the applicatin / service. Usuaully the communication with AD FS uses ssl to secure the transport layer, and the messages are signed, to make sure no one messes with them in the middle. You can, of course, implement such a mechanism by urself. You dont need to get the password from the active directory, you only need to see if the passed credentials (username / password) can be validated, by using the code sample provided here
Basically, if you use WindowsAuthentication to grab the username, store in a variable and then pass that to any services you use, what's to stop someone from hacking your code and passing in another username?
On the client end you can check the IsAuthenticated, but then after that it only lets you grab the Windows Username, not the Windows password.
Is there some way to just pass that authentication object itself without letting it be hacked? Otherwise, I might have to switch back to not using Windows Authentication as my Authentication and custom rolling a user/pass with a db table.
You can't pass user's credentials outside of your server due to "NTLM one hop" behavior. You may be able to configure Kerberos authentication to handle cases when you need user's credentials flow between front end and backend servers.
The other option is to establish trust between servers (i.e. HTTPS with client certificate) so backend server is able to trust user name coming from your server (as it would be the only one with correct client certificate). You will not be able to impersonate the user on backend server as you will on ly have a name.
I created a web service that I want to make more secure by using forms authentication. I added the following code:
[WebMethod(Description = "Login function returns true for success and false for fail.", EnableSession = true)]
public bool Login(string Username, string Password)
{
return User.Validate(Username, Password);
}
My User.Validate function does all the authentication and works fine but I am not sure if it is secure passing the username and password to the web service. Is this any less secure than when a username and password field are submitted through a normal web form without SSL?
Is this any less secure than when a username and password field are submitted through a normal web form without SSL?
That's damnation with faint praise. Submitting a password without SSL really isn't secure.
Anyway, it seems like it might be a good idea to start with the basics. Does that article answer what I think is your actual question ("How should I do this correctly?")?
Your web method is no less secure than a normal web form without SSL. Both are basic POST entries (you could make them GETs, but POST is most likely) that send their payload contents (Username, Password) in clear text.
Just a comment: not certain about your strategy of making your web service more secure by adding an authentication method that returns a simple boolean. Most authentication schemes will require the use of a session or authentication token that must be carried around by the client. In a web browser, this is automatic through cookies and such; it requires active management for most clients consuming a web service.
Depends who you need to trust. Client, Transport and/or Server.
Client needs to know the password to enter, so not a real problem.
Transport can (and should) be encrypted using HTTPS - HTTP is not any good.
Server - do you trust the people running the server? Will users use the same passord on the server as in thier company (giving server owner possible password to try to attack you company account)?
A good sanity check for security of the server is if you are offering a change password page or not. Any web-site that allows the user to change the password, will send the password over the line and it will be available in clear text on the server (can be encrypted on the way). This could be avoided, but I have yet to find a site that does it.
Cheers,
Well, passing password is not secure if SSL is not used. Also, if the service is exposing multiple methods then user has to enter the username and password for every method call or the calling application has to persist this information in some place and might lead to other vulnerabilities.
To avoid all these problems and one of the right way to secure a service is to use something similar to the OAuth protocol. This protocol exchanges the username password for request token and then exchanges this request token for access token. Subsequent calls to the webservice will use the access token and not the username password.