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 ;)

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 ;)

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). So this would mean that unless the client packages there 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.. this 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 users role allows that request it is then processes.

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 ;)

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 ;)