I am developing a WCF based ERP application. My service is using Per Call instance mode and Concurrency mode Multiple.
I am using custom UserName/Password validator for authentication. Since for Per Call services, services instance is created for each call,
I am not sure how to deal with the authentication.
Is it the correct approach to send user name and password with each service request and validate
on the server side?
If so, at the client side, should we store the user name and password entered by the user?
If there are any better ways of doing user name/password based authentication, please let me know.
You can pass credentials in SOAP header instead of passing as method parameters.
For that you need to use MessageContract.
Related
I have an existing WCF service that uses TransportWithMessageCredential security. It requires a username and password and uses a CustomAuthorizationPolicy and a CustomUserNameValidator. This is all configured from within the web.config in bindings / behaviors and all works fine.
However, we have a requirement to add a new method to this service specifically for a new vendor, and I'm being told this new vendor uses a Java client and will not be able to figure out how to authenticate with the credentials in the header, like is required for all the other methods in this service.
So I've been asked to simply take a username and password as arguments to the new method instead, and use those to manually authenticate against our user store in the database.
My question is, since they want this method included in the same service that requires authentication for every other method, is it possible to implement it that way so a single method is exempt from the authorization / authentication policy that all the other methods require?
You could add an endpoint that doesn't use the custom validator
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 have a client, which calls a service (passing it a user id and password). The first service can validate these credentials against users in a database. The first service then needs to call another service, but this second service cannot be passed the user id and password given to the first service (this is a requirement outside of my control).
The services will most likely be on different domains and both exposed to the internet (so security is a big issue here).
I am therefore looking at options for how the second service should check/validate that it is being called by my first service (and not by someone else trying to impersonate it).
One idea I've had is to add an additional service that acts as an authentication service, this could issue a token that is then passed to the second service which in turn calls the authentication service to check the token. Another idea (from a colleague) has been to assign an SSL certificate to each service, and check the certificate when the call comes into Server B - I haven't seen certificates used in this way though so am not sure if it's viable.
This is still at the design stage, so I am open to alternative ideas/approaches.
If you need an easy fix, then creating an extra set of credentials for service A so that service B can be sure it's called from an authorized party without knowing the clients credentials might be enough.
In the long run, something like Windows Identity Foundation sounds exactly like your plans with the authentication service.
So, both A and B parties are exposed to the internet (distrusted environment). Taking into account security requirements what you need is mutual WCF authentication. Certificates are the easiest way to achieve the goal - your server has to ensure that proper client calls it and the client has to be sure it calls proper server (DNS attacks, etc.). That means each party must have public key of the other to authenticate. Check this article for the details on how to configure your server and client.
My question is: I have a web application built using ASP.net and a web service. The web service has to use a different database, depending on which client is logged on.
Is there a easy and elegant solution to do this ?
You can check it by passing client credentials in each request to service.
Ask client to call init(id,pass,...) method with credentials before calling any web method. You can also ask for optional settings in Init, based on inputs you can give client the access token and let client pass this access token to each request, you can check this access token and parse the settings to take action i.e. to call a particular DB connection. Facebook api works in similar way.
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.