Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
In this post, I will go over a few things that application developers should keep in mind as they develop cloud applications using Access Control Service v2. In order for applications to be more secure, everything from your application’s interaction with the user to the data in the backend needs to be more secured. If security is lacking or weak in any one place, the data can be compromised thus rendering the remaining security work futile.
I am presenting below some of the threats that developers need to consider for their applications using the STRIDE methodology.
Threats related to ACS v2 categorized using STRIDE:
Following are key security countermeasures that should improve security for your ACS v2 implementation and rise the security bar.
For Web applications credentials are usually Username/Password pair. For WCF Services ACS v2 uses the notion or entity of Service Identities which can be either Username/Password, Symmetric key, or X509 Certificate. To learn more consider reading the following resource:
No matter what credentials type you use to authenticate your users/callers there are several guidelines you should consider to follow:
Notice though that any communications to and from ACS v2 are performed over SSL/HTTP traffic, but it is solely under your or your identity provider control how the credentials transferred between end users and the identity providers.
Tokens issued by ACS v2 are sent over SSL/HTTPS and also signed either by Keys or X509 Certificates. Consider the following tamper proof measures:
Consider reading the following resources for more information:
Also consider reviewing the following resource focusing on security countermeasures for Windows Identity Foundation (WIF):
The information in this post is based on Windows Identity Foundation Config.xml file that ships with WIF SDK.
<cookieHandler> controls the CookieHandler, which is responsible for reading and writing raw cookies at the HTTP protocol level.
SessionAuthenticationModule uses the cookieHandler to read and write cookies.
<chunkedCookieHandler> may only be present if the cookieHandler/@mode is Default or Chunked. It controls the ChunkedCookieHandler.
<chunkedCookieHandler chunkSize="2000" />
<customCookieHandler> may only be present if the cookieManager/@mode is Custom. It references a custom type which must be derived from CookieHandler. See the comments before the <configuration> element on custom type references.
<customCookieHandler type="MyNamespace.CustomCookieHandler, MyAssembly" />