The services(let’s call them Service A, Service B) behind the gateway are all deployed on the same machine/server. In other words, all these apps are deployed on the same tomcat instance.
What kind of security needs to be added to secure calls from gateway to service A ? I understand we can implement spring security for service A and service B as well but wanted to avoid that since gateway is already doing so and evaluate if there is a simpler approach to this.
Can internal api calls be secured with any firewall rule?
Service A and service B only host rest endpoints.
Related
What is the difference between a Proxy service and API service in wso2esb?
To expose my service I can give proxy URL and API URL then in which scenario both differs? and in which scenario I can use proxy and in which I can use API?
Please help me in understanding..,
An API has resources so it is suitable when you have to perform multiple operations like CRUD etc. then you can call particular resource which will be performing some particular operation.
A proxy service is suitable when you have to perform an isolated operation (single operation).
So, what you can do is, make an API for multiple operations and then create proxy services for each operation.
Moreover, API can be called as REST service and Proxy service is called as a soap service.
Use a proxy service to expose a SOAP web service
You can consume JMS messages or files with VFS, but since ESB 4.9.0 you can use inbound endpoints for that purpose
Use API to expose a REST service
I have the following scenario:
A stateless service with a self-hosted OWIN WebApi. This provides a RESTful client-facing api.
A stateful service, again with a self-hosted OWIN WebApi.
After locating the correct stateful service partition, the stateless service calls into stateful service to access state. It does so via HTTP/HTTPS into the WebApi.
This configuration works fine running on the local cluster and an Azure cluster over HTTP. I'm running into problems though with HTTPS.
Using a self-signed cert I'm able to use HTTPS between the client and the stateless front-end service. However, I can't seem to get the configuration quite right to allow the stateless service to communicate with the stateful service over HTTPS.
I get an exception when the stateless service makes the request to the stateful service. "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." That has an inner exception of "The remote certificate is invalid according to the validation procedure".
I'm a bit fuzzy on security on service fabric, but have read through several articles, SO posts, blogs, etc. on the subject.
Here are my questions:
At a high level, what is the proper way to secure interservice communication in my scenario?
Is a self-sign cert supported in this scenario?
Are the two services in the same cluster? If so, why not just call the stateful service from the stateless one using ServiceProxy?
You can use a self-signed certificate - the error you're seeing is not specific to Service Fabric. There are several ways to bypass it (although obviously it's not recommended to do that in production). Take a look at this SO question: C# Ignore certificate errors?
My understanding on routing service in WCF is this -
The actual services resides in your private network which is not accessible to the world. You then have a routing service as an intermediary which internally (based on inspecting the request) calls the services in protected environment. This routing service is accessible to client and client uses this routing service to communicate with actual services.
Hence, how will the client know about the service contract exposed by the back-end service (as explained in most of the articles on routing)? If from WSDL, then client will anyway know about base address of back-end service and directly call the service instead of routing service. How can we enforce this constraint on client side?
Thought?
Thanks!
Normally, in said cases, you will expose the service contract through other means, such as a statically published WSDL. This is going to be more prevalent in scenarios in which you are using mechanisms such as protocol transitions, as the original, dynamically-generated metadata is going to be wrong anyhow.
For simpler scenarios (in which all you want to do is avoiding exposing your server directly to the network), a reverse proxy might be a preferable alternative in some cases if you're using HTTP.
I need to host a WCF service that will give its clients access to internal business systems on a public facing web server. Obviously I must secure this so that no one from the outside world even knows the service exists, let alone be able to call methods and access the data it exposes.
The overall idea is that the public facing website hosted on the same machine will call the WCF service and then the WCF service will provide it with the required data...
Public Facing Web Site <-> WCF Service <-> Business Systems / Databases
So I need to understand how to secure the service so it can only be accessed via the public facing website.
Ideas I had..
IIS filtering so that the IIS Site hosting the WCF service will only accept requests from a certain IP address.
Obscure port that will not be allowed through the public facing firewall.
Protocol such as NetTCP or NamedPipes
But what about the actual WCF security set up? As both the Public Facing Site and the service are on the same machine is Windows Authentication as option? Questions I have regarding this are...
Should the service client and the service simply use Windows Authentication?
Do I need specific user accounts as opposed to Network Service? If the website runs under network service would this then automatically authenticate to the service?
My objective is that someone in the outside world should not know of the services existance or be able to make access to it.
Thanks in advance.
Technical environment is: IIS7, .Net 4 and WCF 4.
I would suggest you create a http handler '.ashx' and use that as the endpoint for client requests.
If your using asp.net you can secure it by using simple forms authentication and retrieving username and password from the request headers to authenticate the request.
Then execute any requests to your business webservices which is also secured by your forms authentication.
Cheers
I have a callback service that is hosted over wsDualHttpBinding. I'm looking to add a client that will poll for the data rather than receive the callback (will be a mobile device using wince for demo purposes). I was curious what the best way to do this is? You cannot create a client proxy using NetCFSvcUtil with a service hosted with wsDualHttpBinding (I understand that), but you cannot host a callback service over basicHttpBinding. I really need the same service hosted over both basicaHttpBinding (clients will poll for data) and wsDualHttpBinding (callback will notify clients of data). Any ideas on the best way to handle this without creating two separate services to host the same data?
What do you mean by two separate services hosting the same data? Do you expect to share same service instance to handle both wsDualHttpBinding and basicHttpBinding requests?
Your current problem is that service interface for duplex communication cannot be used for basicHttpBinding. You have to create second service contract and implement it in the same service. In that case you can expose two endpoints for the service: one duplex with WSDualHttpBinding and one with BasicHttpBinding. Endpoints must have different relative addresses. From the perspective of the client those endpoints are separate services - each of them requires separate client proxy. So unless your service is singleton you will have new service instance for each client proxy. New service instance means no data sharing.
Thera are some possibilities to modify this behavior but it means replacing Instance provider.