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
Related
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'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'm developing a WCF RESTful web service with C#, .NET Framework 4.0 and Entity Framework 4.4.0.0.
On a SQL Server database I have a table with users and I want to check if an user exists on that table sending login and password.
I have this URI: /users/{user_id} to GET an user using its UserId.
I think, I can do this: /users/login/{login}/password/{password} but I don't know if this is the right way to do it because login and password are public.
How can I check if exist an user with the same login and password without showing them on the URI? (Maybe, /users/login/{login}/password/{password}, this is the right way).
NOTE: the password is encrypted.
If you are building a RESTful API then really it should be stateless - which means sending the user/password on each request or a token on each request.
You will need to run the site under SSL for it to be secure. Your user/password or token should be in the header. For a simple site I would recommend using Basic HTTP authentication (google it if you don't know what it is). You base64 encode the username/password and send them with each request. Have a look here:
http://www.codeproject.com/Articles/149738/Basic-Authentication-on-a-WCF-REST-Service
One more thing - I may be wrong as I don't know the details of your project but I don't think you need a 'confirm' service. It sounds like you have this for the purposes of logging in. I would suggest that when a user logs in you direct them to your dashboard or landing area. If the user is not authenticated at this point then redirect to login.
WCF (REST) services are supposed to be stateless. Use a different way of authentication. See User authentication for mobile clients in RESTful WCF 4 service and User/Pass Authentication using RESTful WCF & Windows Forms.
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.