I am currently following this scenario
Instead of a Windows Forms client, I have an ASP.NET MVC web app.
I am a little worried about the sending of the username and the password
on every call to the Web Service.
That means I will have to carry this information all the time in the session.
Wouldn't that be little security problem ?
Why would you have to carry the credentials all the time in the session? According to the example you're following, they're being set in the proxy (when it's created).
If you're worried about having to cache the credentials for recreating the proxy as needed, then you can cache an instance of ChannelFactory, and then generate new proxies from that instance as needed.
Regardless of what path yout take, the credentials are going to have to be stored somewhere, somehow, unless your application prompts the user for their credentials for every WCF operation.
You can implement WS-Security in your service.
This means you can send user credentials in the header of the message encrypted. Lots of examples out there for this.
Related
I have a JAX-RS application deployed under tomcat and a mobile app.
I would like to know how to make the webservice usable only by the mobile application, in other words, allow access only for a given application
When a request comes in across the internet, there's not really a safe way to be sure what application sent the request. Applications can identify themselves however they want. You could, if you want, attempt to hide credentials in your application, somehow, and have it log in with those credentials. But if anyone discovers those credentials, they can write a program that uses them to pretend to the your application. The problem is that you cannot count on any control over the client system. The client system can always be altered to pretend to be something it is not.
From my perspective, you can add username/encrypted password in the invoke request, and then compare it with the ones saved in the server side
If you really want to, you could implement some form of cryptography. For example, the JAX-RS service can send a 401 forbidden and provide a nonce for the client to sign with its private key, and then send back to the server in the Authorization header. Otherwise, stick to HTTP authentication. If you are communicating via HTTPS, you should be fine with basic auth.
I've setup security in my RESTFUL WCF services using Custom Basic Authentification (thus desactivating the iis Basic Authentification and not using Windows Accounts Login at all; my service is hosted by iis) using the following link.
blog link
I understand the consumers have to implement a client to pass credentials in the request header.
It is 64bits based encoded and we can see credentials passing in firebug network tab while debugging (it is always the same string encoded <=> same credential .......)
So, in addition, to enforce security I will add SSL to encrypt the url :
https://myrestfulserviceurl.com/Method
Now the consumers ask me why we don't just put the login and password in the url request i.e
https: // myrestfulserviceurl.com/Method?login=XXX&password=YYY
(also combined with SSL)
Thus the change requires to add login and password as parameters in my Operation Contract and call a method for authentification in my method "Method".. etc etc
My question is :
What is the difference (both scenarii will use ssl) between Custom Basic Authentification (credentials in request header) & simply passing credentials in url in param ?
I mean : I'm just asking myself why I do bother to implement Basic Authentification. Passing credentials in url or in header look similar : it's passing stuff in the request. But talking in term of security, it looks the same ?
Basic Authentification looks not more secure excepted the 64bits based encoding.
Correct me if i'm wrong.
I am just looking a reason why implementing Custom Basic Authentification.
Any idea/advise?
Thanks
The main difference that comes to mind is to do with how visible the data is and how long it is likely to be retained.
For instance, assuming SSL is terminated at your application server, values in the get parameters are likely to be automatically logged to your file system (in request logs for instance). Having usernames and passwords in there is not ideal as it makes it much easier for them to be leaked.
If SSL is terminated at a loadbalancer or some similar proxy, then the usernames and passwords could be saved in request logs on servers you may not be thinking about and probably have less control over.
By contrast, the Authentication header is much less likely to be logged to places you're not expecting.
I thought about doind this myself and decided against it because i wanted the Restful URL's to focus only on the operations and keep security out of it, for example I might want to re-use the same code on a different application.
Also Im not sure but i think there could be a security implication concerning replay attacks, if someone obtained the link then they could execute it in any http client. If you used the authroisation attribute in the http header you could avoid this by putting an expiration on it. Also i think its better to hide this information from the html page body.
The dude who wrote this http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/, which is taken from his book "Pro ASP.NET web Security". Gives a pretty decent example of creating a token which you could then use in the http header "Authorisation", like: Authorization: Basic d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk
Basically, I have the following scenario and information:
We're using HTTPS.
We want to authenticate a user by user/pass when they first log in.
After they are authenticated, I want any future calls to OTHER services (not the login service) to use the username and some sort of session (in case the password changes in the middle of a session).
I want to make sure my sessions can timeout and control them in a way that if a user tries to call a service and they don't have a session they get an error (cause they haven't logged in). Not sure if there's a WCF built-in way to do sessions this way or if I'll have to do something customized with a database.
I think we want to use WSHttpBinding (not BasicHttpBinding), 90% sure on this.
I just can't seem to figure out how to do this. Often time's I'll find information on the client code doing client.ClientCredentials.UserName.UserName = username and client.ClientCredentials.UserName.Password = password. But, that just doesn't work because what is my server checking against? I'm trying to grab that info and validate it against a database of user/passes. I'm not looking to use Windows Authentication or that sort (because I don't care who is logged into the computer, just who is logging into the app).
You want to use a Secure Token Service (STS) to authenticate and get a Security Token (maybe SAML) back that identifies the user which can then be passed to your other services and they can just use the identity information to identify and authorize because they trust the STS has verified the user's identity up front.
This is a large subject to discuss, so I suggest searching for WCF STS and doing some more research, but that's definitely the direction I'd recommend going. If you're going to build your own STS implementation, I also recommend looking into using the Windows Identity Foundation (WIF) components to ease your development efforts.
Here's the download link for WIF v1.0 which is the latest version at the time of this answer.
(I tried searching, but couldn't find any truly helpful links.)
We are implementing a set of WCF services. What I would like to do in these services is have the clients (which will be trusted application servers) be able to pass a token of some sort to the web service to authenticate. I do not want to be required to pass username/password on the initial or subsequent requests (because in some cases the calling application server may not have the password). Windows and Kerberos are not usable in our specific circumstance.
I had thought to just create a simple custom UserNameSecurityTokenAuthenticator class and modify it so that if the password is empty, it takes userName as the string-encoded token value (obviously checking the token itself to verify that it's valid at that point), but if the password is not empty, forwarding on the username/password to a MembershipProvider for checking. Basically I'd like to overload the username/password authentication to provide for token passing as well.
Is this possible? Can I simply plug in a token authenticator like this, or is there some other simple way to "intercept" requests like this (and update the actual username value from the decrypted token)?
Or is there some other incredibly simple way to allow the client to pass a custom token and have the server accept it that I'm just missing?
If it's a fairly controlled environment and not too many clients involved, then I'd try to set up something along the lines of the B2B scenario securing the transport link using certificates on both ends.
Certificates are not bound to Windows or an AD domain, and setting them up is a one-time job.
Read more about that WCF security scenario:
MSDN: Transport Security with Certificate Authentication
Fundamentals of WCF Security: Business Partner Applications
. WCF Security How-To's
I'm rather new to SOA and therefore experimenting around.
Currently, the part that creates the biggest problem to me is authentication, my current thought about it involves the following:
The client sends some kind of authentication message to the authentication / user service, this service queries the db and if the user is found and the password is valid, it will respond with a session id, this id will be used in all further requests of this client.
This seems rather ok to me but I don't know how I should handle the requests to other services, I thought of three different approaches.
Every service asks the authentication service if the session is valid and if so, what roles the user is in. The authentication service looks in the db and replies accordingly.
The authentication service keeps all session information in ram and responds without the db roundtrip to the requests.
The authentication service sends an authorized message to an esb, the esb forwards this authorized message to every service and these services cache it. No further requests to the authentication service would be necessary. If the user logs out or his roles change, another message would be send around and processed by all services.
I think the first approach creates too much stress on the authentication service / db but takes the least effort to implement.
The second is still very easy to implement but the stress on the authentication service remains almost the same.
The third is a little more complicated to implement but would has reduced response time as no trips to the authentication service take place. Though, if there are too much session information this approach would just fail and scalability is hardly given.
The best approach should be like this if all the services are internal,
The authentication service issues a token the the service client.
Service client includes the token in the SOA message wrapped in WS-Security or something similar.
The service should validate the token with authentication service before providing the service.
For external services, I suggest you look at federated solutions like SAML.
Don't do premature optimization. Your option no. 3 which you acknowledge will be more complicated to implement is unnecessary. Choose option no. 2 if that's what you can implement fast. You can profile later and change it, but I'd bet money that you won't have a 'bottleneck' when going with option 2.