We Keep Coding

How to restrict access to web resources from internet but expose in intranet

I have a website written in ASP.NET WebForms, which accesses web services that are written in ASP.NET WebAPI. For security, I closed port 8079 (web services) so that web services could only be accessed via the website, but that it would not be possible to request web services directly from the Internet. When I request a page on a website, through the Fiddler program, I see a request for a website, but I don’t see a request from a website for web services. Everything works well. But now I have made another website written in AngularJS and I want this website to also access my closed web services. Is this possible through AngularJS? Below is the request code for web services via ASP.NET website.
HttpResponseMessage response =
client.GetAsync("http://localhost:8079/api/values/5").Result;
if (response.IsSuccessStatusCode)
{
Task<string> data = response.Content.ReadAsStringAsync();
result += data.Result;
}
As a result, the site(AngularJS) and ASP.Net MVC Web Application should be available on the Internet, and web services (ASP.NET WebAPI) should not be available on the Internet.

Currently, the client accesses the web services directly, but it’s necessary to make the client access the web server and the web server access the web services
Even if you create another ASP.NET app (a kind of 'facade') that handles requests from the client, and invokes web services internally, this alone won't solve the problem:
If the facade accepts requests from any client and just sends them to the web services, it is not different from exposing the web services directly to the internet.
As #Andrei Dragotoniu pointed out, you have to secure your services by only accepting requests from authorized clients.
How to authorize access to web services
A common way of securing access to web services is JSON Web Token (JWT). The token contains encrypted claims that explain the identity (and maybe other aspects) of the client. Typically it works as follows:
A new token is generated on the server upon successful authentication of the client. The authentication can be either manual (a login form), or automatic (for example, with OAuth).
Once the token is generated, it is returned to the client. The client then starts attaching the token as an HTTP header to every request it sends to the web services. On every request, the web services validate the attached token.
This blogpost provides more information and examples of using JWT in C#.
API Gateways
The requirement of limiting access to web services to an internal network is not uncommon. A typical solution here is API Gateway.
(from Wikipedia) Gateway: a server that acts as an API front-end, receives API requests, enforces throttling and security policies, passes requests to the back-end service and then passes the response back to the requester. A gateway often includes a transformation engine to orchestrate and modify the requests and responses on the fly. A gateway can also provide functionality such as collecting analytics data and providing caching. The gateway can provide functionality to support authentication, authorization, security, audit and regulatory compliance.
More on API Gateways in this article. One of the most popular API Gateways is Kong.

Even if you deploy your web service in intranet, you cannot consume the web service from client browser (Angular or JS Applications).
One possible solution could be,
Deploy the web service in intranet web server.
Create a proxy web service in the edge server (they are both intranet & internet facing). Proxy web service should just expose the required methods by obscuring the original web methods.
Consume proxy web service from client-side applications.
Otherwise, client-side applications can never consume the intranet web services.
Optionally, if you create NodeJS, ASP.Net based web applications, it can be deployed on edge web servers that can talk to intranet web services and users (living in the internet) cannot access web services directly.
UPDATE:
Moreover, based on your code above, it looks like you are trying to consume web service from .Net Runtime Managed Code (ASP.Net MVC). Well, in that case, AngularJS will ajax to your controller-action. Then controller, in the edge server, can talk to any intranet web service. AngularJS need not talk to Web Service. It is straight-forward now.

"When I request a page on a website, through the Fiddler program, I see a request for a website, but I don’t see a request from a website for web services"
That statement is true in a very limited context, but the reality is much bigger than that.
The requests from a website to its own API can easily be seen by using browser tools for example ... hit F12 in any browser and look under the Network tab, this is something anyone can do to see what a website ( any website ) is doing.
You need to protect your API somehow. You can use something like OAuth2 or you could do it at server level. You can lock down a server to only accept connections from your website's IP address for example. You can also make it so that the server the API is on is completely locked down. You can lock down the API.
You just need to realize that you do have a security issue if you don't do something. The tech stack you use is irrelevant for this.

Securing WCF Service Call Between Server Applications with Federated Security

I've got two MVC sites that use the same STS for authentication. I need to create a WCF service as part of one of the sites that allows the other site to retrieve data.
These sites could be on different machines accessible over the internet (although currently they're on the same machine) and the WCF service should only be able to be accessed from the client site. The authentication token used to log into the client site should be passed through to the WCF service.
I've been looking at the different WS-Security options available (Transport, Message etc) and it's not quite sinking in 100%, and I feel like I'd end up implementing something that seemed secure but wasn't actually secure due to a lack of understanding. Any help much appreciated.
Edit:
My first attempt was with transport layer security and setting the WCF service virtual directory with require SSL in IIS. However that left me with an error of:
"The remote certificate is invalid according to the validation procedure."
And I had no way of ensuring that a specific client was connecting to the service, only that a client had a certificate from a trusted CA. At least as far as I know. I'm probably missing something vital here.

The authentication token used to log into the client site should be
passed through to the WCF service.
In this case you should be requesting an "ActAs" token from the STS:
The WCF service should be configured as a Relying Party of the STS.
The MVC site should call back to the STS and request an ActAs token specific to the WCF service.
The MVC site uses the ActAs token to call the service.
The motivation for the complexity: Delegation, or traversing multilayer architectures
Since you mentioned WS standards:
Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)
Not knowing your STS its hard to say more, but Googling "ActAs token" will probably give you what you need.

WCF User Authentication & Authorization

I need to find a way to authenticate/authorize users in a WCF-service. I'm using an external authentication service which stores the credentials of the users.
Eg. "Bob uses our loginmethod, we send the credentials to the authentication service, the service lets us know if these credentials are correct."
If Bob sends another request, we need to know if Bob is already authenticated.
Now a session is being created on the client, but it needs to move to the server-side. We can not rely on clients for security.
Can this be solved by using security cookies or do any of you have a better suggestion?
EDIT! I can only use the authentication server and do not have access to it

The problem you are describing is a well-known one that had (at least) two standardized solutions.
Federation using WS-Trust
The first option is a SOAP based one that uses active federation based on WS-Trust. In this solution:
Your client provides credentials to the authentication service
If the credentials are valid, the authentication service returns a signed (and encrypted) token to the client. It is encrypted so that any information contained in the token remains confidential - even the client cannot read it. It is encrypted with a public key belonging to the your WCF service. It is signed with a private key belonging to the authentication service.
The client submits the signed/encrypted token to your WCF service. The service can decrypt it because it holds the private key for decryption. It can trust it because it is signed by the authentication service.
Based on the content of the decrypted token, the service can establish the client identity and make an authorization decision.
In this model, the usual terminology is:
Your authentication service the Security Token Service
Your WCF service is the Relying Party
your client is the Client
This sounds complex, but it is very well supported in .Net and WCF using Windows Identity Foundation. There are many samples available much of it (maybe all) can be done via WCF configuration rather than code.
This is well suited to scenarios where the clients are crypto-capable (like your .Net clients) and where good frameworks exist (like WIF). It is not so good for low spec clients such as browsers and some phones, or where you are not in control of the clients.
It is commonly used in enterprise scenarios, including enterprise-to-enterprise federation. It is used less often in internet scenarios.
the strengths of it are
It is standardised and therefore generally well supported by frameworks
It means that your WCF service never has to handle the client credentials (= more secure)
It makes it pretty easy to switch to different authentication services (because it is standardised). For example, on-premise AD and Windows Azure AD both support this, as do other independent identity services
An overview can be found here:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
And Google will show you lots more walkthroughs and examples.
Federation using OAUth 2
In this solution:
The client displays some UI provided by the authentication service (generally a web page)
The user enters their credentials in that UI and the authentication service authenticates and eventually returns a token to the client. The nature of the token is not standardised, nor is whether it is encrypted. Generally it will be at least signed.
The client submits the token with each request to the WCF service
The WCF service authenticates the token as in the previous solution
In the OAuth terminology:
Your authentication service is the Authorization Server
Your WCF service is the Resource Owner
Your client is the Client
Again, this sounds complex, but it is reasonably well supported in .Net. Probably not as well as the WS-Trust approach though at the moment. It is supported by Windows Azure AD and on the client side, using the Windows Azure Authentication Library. May other services use this approach - e.g. Facebook.
This works well where
Your client is low spec or not crypto-capable (e.g. a browser or some phones)
You do not control the client (e.g. a third party application is accessing your service)
It is very commonly used in internet application where you as an owner of the WCF service don't necessarily know the users or the clients. It is a less complete standard in some ways (e.g. it does not define exactly how the authentication happens) and as a result, it is less easy to switch to alternative authorisation servers.
The strengths of it are:
It is simpler and therefore has wider platform support
It is growing in popularity and therefore the library support is getting better all the time
The user never enters their credentials into your UI, only into the auth server, so it is more likely to be trusted (in internet scenarios)
It has a built in way of controlling the scope of the permissions granted to the client, and revoking those permissions, so again it is more trusted in an internet scenario
The official .Net support for this is in the Windows Azure AD Authentication library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
There are other, open source components too, such as DotNetOpenAuth
http://dotnetopenauth.net/
Which solution would be best for you depends mainly on the nature of your authentication service I would say. And on whether you are in an enterprise or internet scenario. If the auth. service could be easily adapted to be a WS-Trust Secure Token Service (STS), then that would be a good route. If adding some web UI to the auth. service is feasible, the OAuth might be better.
Or, if neither option is feasible, you could just borrow the patterns form one approach and use that without going for the full standard.
Good luck!

How to get started with OAuth to secure a Web API application?

I have a Web API application and I've understood OAuth would be the standard security model for APIs where an Authentication Server would become responsible to generate Authorization Tokens so that the user can send to our server and consume the services.
I'm very new to this but I understand the roles involved:
Resource Owner
Client
Resource Server
Authorization Server
But what is OAuth exactly in practice, not in theory? Is it a .NET library? Is it a service provided by a separate Company? Is it something I can configure on my local development machine and see how it works?
How to get started with OAuth to secure a Web API application?

OAuth is a protocol; the current version is OAuth 2.0. More to your question, that link lists several implementations of the protocol in various technologies. For use with the .NET Web API you're probably interested in DotNetOpenAuth which provides implementations of both OAuth 1 and OAuth 2.
I'm using DotNetOpenAuth in an app I'm working on now to secure a .NET Web API. I've got an OAuth2Handler which extends DelegatingHandler which is inserted into the Web API pipeline before incoming requests reach any controllers. OAuth2Handler does the following:
Instantiates a DotNetOpenAuth ResourceServer
Calls ResourceServer.GetPrincipal() which reads and decrypts an access
token (issued elsewhere by the AuthorizationServer and returns an
OAuthPrincipal (In my case I'm reading additional data that the DotNetOpenAuth implementation allows you to pass and creating a ClaimsPrincipal.)
Assigning the IPrincipal containing the user information read from the access token to the User property of the thread and current HTTP context so it is available from the ApiController.User property in the service controllers: httpContext.User = Thread.CurrentPrincipal = principal;
Honestly, getting this all working (e.g. setting up the authorization server, resource server, certificates, etc.) isn't trivial. Unfortunately there didn't seem to be a good guide on the DotNetOpenAuth site. Here's a few other tasks you'll have ahead of you if you go this route:
Implement IAuthorizationServer - This is the interface provided by
DotNetOpenAuth that allows you to plug in to the library and use
their implementation to issue OAuth2 access tokens. You'll also need to implement INonceStore and ICryptoKeyStore which I did using an EntityFramework context for storage.
Configure Certificates - The AuthorizationServer and ResourceServer each use certificates to encrypt/decrypt the access token ensuring they are only accessible to each other. I built some custom configuration so I could manage this configuration in the web.config files of my authorization server app and my Web API services (resource server).
Manage Refresh Token - When first requesting an access token from the authorization server you'll get back (depending on your configuration) both an OAuth2 refresh token and an access token. The services use the access token which should be short-lived. The refresh token is used to get more access tokens. The refresh token should be kept secret (whatever that means in your scenario). For me it means the refresh token is never exposed to client-side javascript in my web app.
I hope that helps give you a high level idea of how to get started with OAuth and .NET Web API. Here's a blog post demonstrating some of these steps. This SO answer gives a few more high level details of the client side of the picture.
(The DotNetOpenAuth online docs appear to be down right now... sorry for no links to them; Apparently it has happened before).

Brokered Kerberos web service security over the Internet

Is it possible to use Brokered Kerberos Authentication for web services over the Internet? I'm looking at web services security for an environment which already has Active Directory. Due to the existing architecture the web services will be quite chatty and I have no control over this architecture. It may take up to 6 web service calls to perform one business process .
There is concern over authenticating multiple times and the overhead this will incur. From my initial reading of brokered kerberos authentication, once the user credentials are provided then a Kerberos security token will be returned and authentication is not required for each web service call.
I'm envisaging a system where the user credentials are passed to Active Directory via a web service call and the Kerberos token is returned. This token is then used for all subsequent web service calls.
Is this possible or am I heading off on a tangent? If I am heading off on a tangent is there a preferred approach for this? I've finished reading the Microsoft Web Service Security: Scenarios, Patterns and Implementation Guidance for WSE 3.0 and still a little unclear.

Consider leveraging the SAML protocol as a way to exchange assertions via WS-Security.