WCF - Is this a good security Architecture?

Question

I am building an information recording system (WCF based) for a business that is accessible by staff over the internet. This software will not be distributed and there will only be a handful of users with the client application installed.

Due to the fact that the stored information is highly sensitive, I would obviously like to authenticate and authorize any service requests. So, there will be around 4 service endpoints dedicated to handling a variety of requests. In order to protect these services, I was thinking to authenticate any requests with a token-based system (which is effectively just a GUID). This would mean that unless the client packages their requests with this token they cannot access those services! Right? Now, in order to retrieve a valid token, the client must connect to the security token service, which begins with mutual SSL authentication (to prevent man-in-the-middle-attacks), then the user must provide their login details (encrypted of course), then if the details are valid they are provided with a token. The token is then logged, along with the users details. Now the client can send valid requests to the other services. When one of the other services receives a request, the token and user credentials are checked against the "current user store" and their role is retrieved. If the user's role allows that request, it is then processed.

Sorry if that is all a bit long winded! But basically what I am asking you security gurus is: does this sound like a decent architecture for this system? should I make any improvements? or should I scrap this architecture all together and go for something else? (if so, any guidance would be appreciated!)

I respect the fact that I am not a security wizard, however I am willing to learn! So please be nice ;)

Answer 1

If you know what you're doing, using WCF isn't difficult. If you know what you're doing, using WCF with an STS isn't terribly difficult. If you don't know what you're doing it's all terribly difficult. Who am I kidding, it's WCF, so it's all difficult. :)

Generally speaking your architecture falls into the federated trust category, as you're using the STS to provide authentication. I'm a little confused as to why you say the token is effectively just a GUID. Normally with WCF it's a SAML (wrapped in a WS-Trust container) token, which contains attributes/claims about the given identity. A lot of times the user's roles are contained in the token already. It's up to the STS to provide the roles, and your services just check to see if the incoming identity has the requisite roles (in a simple scenario, anyway).

From a security perspective it all gets a bit messy for a few reasons:

• WCF is a PITA
• WCF security relies heavily on certs, which introduce their own issues
• STS are difficult to build securely so the recommendation is to use pre-build STS
• Using pre-built STS rarely do what you want them to do out of the box

If you can work through these issues you can have a reasonably secure implementation of the services, however that's relative to what you're wanting to protect against. What are you wanting to protect against and what aren't you wanting/willing to protect against?

One of the weakest points of a federated system is the crypto. How do you protect the keys such that the STS can use them, but people can't steal them? You said you wanted to use client certs for mutual auth... how are the clients protecting those keys? How are you issuing those keys? You said client certs for SSL mutual auth... does that include certificate-based auth for the STS auth of the users, or are you going to use username/passwords? Are you going to encrypt the token between the STS->client->service, or will it be plaintext? Normally you'd encrypt the token as it contains sensitive information. How do you protect the encryption keys for the services?

A federated trust is a good architecture, but it really depends on the use case. It's usually when you're wanting to decouple the authentication/authorization of users from the services themselves, and centralize them into a single source. Since you've got 4 services, it sounds like it might be a good thing. However there is a huge added overhead with the STS (this now makes it 5 services), as well it's usually hosted in it's own site.

For more information take a look at the Thinktecture.IdentityServer project: http://thinktecture.github.io/Thinktecture.IdentityServer.v2/. It's an open source STS built by people that have worked closely with Microsoft's WCF and WIF team.