Can a client be created to only receive a read-only copy of the cache
such that the client application is not allowed to make changes to
the local cache nor make changes that will reflect on the server
nodes.
I have started a process that acts as a client for a gemfire server.
I would like to fetch all the cached data from the server at once in
the client side of the cache and only then continue with regular
functions of the client. Is there a way the client can make a call to
fetch all data it is interested in and get notified when all the data
has arrived in its local cache?
You can use GemFire security to create a read only client. You will need to implement com.gemstone.gemfire.security.AccessControl interface on the server side to reject all write requests from the client. You would also want to implement the Authenticator interface on the server to establish the client's identity.
From the client you need to pass in the credentials using the AuthInitialize callback. Please refer to the security section of the documentation and this wiki page for more details.
Regarding your second question, I would like to ask if your client is capable of caching all server side data, why do you need a client/server architecture? Could you not embed the server within your application itself?
I have created an API that should only be accessed by certain client applications.
The users of these applications do not (necessarily) have to log in to use the client application. I will hand out API keys, but these will be visible on the client app, so they can also be used by other applications (?).
Is there any way to make sure the requests are coming from a specific client application, for example because they are hosted on a certain domain? I guess origin headers can easily be spoofed.
API keys are typically used to authenticate applications to a server. You are not saying what type of client you are using (native, web app, JavaScript?) You're correct that the API key may be read by another application on the client if that client has the same permissions (running in the same security context) as your client.
You could use client certificates to have the application identify itself. But this may be a pretty heavy-handed solution depending on the security thread you're trying to mitigate. And even here an application in the same security context has access to the private key.
All other info in an HTTP request is easy to falsify.
I need to implement a model, where only an authorized set of clients can use a WCF server. I thought of something along passing an AUTH structure as a param inside each method call. Is this the best method to implement this kind of security, or is there an easier/better way of doing this?
for example i developed and publish the service like below:
http://MyServer.my.com/MyService[^]
By default any any one who know the URL can consume the service.
How i can set specified Set of client can consume the URL.
Also how can we assure no one can change the data between communication.
For eg: client send request for Balance Enquiry service with reponse 500 Rs but some one tried to change it to 500 Rs.
For authentication you can use basic authentication. If using IIS, Web Service users can be local users that have read permissions over the svc file.
For channel security you can use transport mode (https). You will need a certificate for this, but it can be a self signed created by you.
This example sets server and client:
http://msdn.microsoft.com/en-us/library/ms733775%28v=vs.110%29.aspx
After couples of WCF tutorials, I could develop a WCF client/Server application, both service and client applications are Windows Forms Application. I can call service using each client by specifying UserName and password. My WCF service applications also shows all the connected clients with their username as well. But, When multiple clients send a request to service then I'm not being able to identity which user has called the method. This is important as my application tend to have its own session for each client processing, just as any regular ASP.NET application has. Each user have their own Identity and its own Application Domain.
Moreover, I want my service to send messages back to client, so I have implemented callback contract. In addition, I'm using netTcpBinding as my applications need to run on my intranet.
How can I implement this scenario in WCF client/server application ?
Any help please ??
Thanks
Thanks for your previous reply. Its really helpful to me.
Now, What If I want to use custom authentication using username and password.
Lets assume that I have 50 clients with valid username and password. How can I get an identity of a client (out of those 50) whose is invoking a service method at a particular point of time ?
Thanks
In your server side code, you should be able to retrieve the caller's identity from the security context - something like:
if(ServiceSecurityContext.Current != null &&
ServiceSecurityContext.Current.PrimaryIdentity != null)
{
string userName = ServiceSecurityContext.Current.PrimaryIdentity.Name;
}
If you're calling a service with Windows authentication (which might also work for you - if you're on a corporate LAN, as it would seem) - you should be able to access the security context's .WindowsIdentity instead (this will be null for any other authencation mechanism).
I have a set of .NET applications running in a public web environment which connect to a centralized component made up of web pages and web services.
Is there any way to implement a security feature to make the centralized web pages be sure of the caller applications identity? Making a post and supplying a querystring parameter stating the caller application is a naive solution, someone can manually change it.
Any ideas? Tks in advance.
Assign secret keys to each client-server pair and use them to sign messages passed between client and server (using HMAC for example).
TLS/SSL/HTTP. You just need to enable client authentication. SSL is usually only used in the scenario where the server needs to be authenticated. But the server end can be configured to authenticate the client also. Digital certs need to be installed on both ends. This then uses all the appropriate crypto to do the job, ie. public authentication, establishment of secure channel, using Diffie-Hellman, RSA, AES/3DES, whatever you configure.
Take a look at this post. Good place to start.
Another option, perhaps have you look at OpenID?
The current situation:
Servers A, B, and C are trusted and controlled by you. A visitor comes to site A and views a page that sends data to site C, and the data contains something like "origin=A". We're concerned that the user will change that to "origin=B".
A simple fix:
You control all three servers, so let them communicate to verify incoming data. For example, A will change "origin=A" to "origin=A&token=12345", where the token value is random. The user tries to tamper with it and sends "origin=B&token=12345" to server C. C makes a trusted connection to B, saying "Did you send someone to me with token 12345?" B says "Nope" and C knows to reject the request.
This can be arbitrarily elaborate, depending on your needs and whether you're using https. Maybe tokens expire after a certain time period. Maybe they're tied to IP address. The point is that server C verifies any information that comes from the end user with servers A and B.
Are you asking about single-sign-on? (i.e. someone authenticated on AppA should also be able to use AppB and AppC without re-authenticating)
You can do this by configuring the machineKey for your apps so they can share asp.net authentication tokens.
The company I work for currently uses shared forms authentication cookies across the enterprise by using the same machine keys on each web server. However, this is not ideal if you wish to SSO across different domains and it's not very neat for windows app that need to come into the web farm to use the web service methods...
So, where we have to do this we are using SAML
But to clean this all up and make it more unified and more secure we are beginning to implement Geneva
If you communicate with the web services and web pages using http post, you avoid putting the info in a query string.
Send the data over https so that it cannot be tappered with.
You then need to make sure that the call is coming from your public web environment. One way of doing this is to use windows authentication, based on the identity of the application pool.
EDIT 1
Take a look at this link: http://www.codeproject.com/KB/WCF/WCFBasicHttpBinding.aspx
It shows how to set up windows authentication for WCF basic http binding.
Maybe look at the HTTP REFERER field. Under certain conditions this may be treated as reliable. In particular: An A mimic site won't send users from A to C according to HTTP REFERER.