I have a front end MVC application in a web role, protected by WIF and ACS, which I would like to be my Azure application’s only exposed surface. It connects to a number of back end services, some worker roles and some (for the convenience of adding service references in VS, or because they use WCF Data Services) web roles. The back end service roles have only internal endpoints.
My understanding from the MS literature is that internal endpoints are available only to other roles with the same deployment. Given this, it seems redundant to apply any kind of transport or message security, or authentication, between the MVC web role and the back end services, which is presumably why https is not available on internal endpoints.
My question is: how secure is this? Is there any way an endpoint could be discovered from anything other than one of our deployed roles? Is there any reason to incur the overhead of additional security on any of the inter-role bindings?
A service represents an isolation boundary, unless you declare an endpoint as an “input” endpoint, it cannot be accessed outside of this isolation boundary. The implemetation of this boundary is a private network branch with no addressability to other branches.
Keep in mind that internal endpoints are not load balanced. So there is a trade off. I wrote some stuff up on endpoints awhile back that might help consolidate things a bit.