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:
- Identity Spoof. The identity can be stolen as a result of poor credentials management, insecure transfer over the wire, accepting untrusted tokens, or tampering the token.
- Tampering with the token. This can lead to materialization of other threats such as Identity Spoof, Elevation of Privileges, or Denial of Service can be result of failure to tamper proof tokens by, for example, signing them.
- Repudiation. This is the case when user denies action he performed. Can be result of poor logging practices and failure to securely transfer the identity, the token.
- Information Disclosure. In the context of ACS v2, if the information transferred in the tokens considered confidential depending on business requirements then it might be exposed as a result of transferring tokens in clear text over clear unprotected communications, storing tokens on persistent storage in clear or for prolonged period of time to allow brute force attacks to crack the cryptography.
- Denial of Service. One example of denial of service might be the case when the application uses Error URL feature and the error handling page is configured to require authorization – this will result into infinite redirect loop.
- Elevation of Privileges. ACS v2 issues tokens to successfully authenticated users/requests. The token include claims that can be used for authorization. If the claims can be easily tampered the attacker could elevate his privileges.
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:
- Service Identities Explained
- How To: Add Service Identities with X509 Certificate, Password, or Symmetric Key
No matter what credentials type you use to authenticate your users/callers there are several guidelines you should consider to follow:
- Do not store credentials.
- If you need to store your credentials – store them encrypted. In case of X509 certificates consider storing them in certificates stores vs. as files.
- Never send credentials over unencrypted traffic, use SSL/HTTPS to protect credentials over the wire.
- Set aggressive but reasonable time-outs for the tokens. The time-outs can be configured when setting Relying party. Consider reviewing Token lifetime section in Relying Party Applications Explained.
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 Tamper Proof
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:
- Token signing
- Add an X.509 certificate signing credential if you are using the Windows Identity Foundation (WIF) in your relying party application.
- Add a 256-bit symmetric signing key if you are building an application that uses OAuth WRAP.
- Token encryption
- Optionally, Access Control Service can encrypt any SAML 1.1 or SAML 2.0 token issued to a relying party application. Note that encryption is not supported for SWT token types. Access Control Service encrypts tokens using an X.509 certificate containing a public key (.cer file). The token is then decrypted using a private key possessed by the relying party application.
- ACS can accept encrypted tokens from AD FS 2.0 identity providers. In this scenario, the X.509 certificate with the private key is hosted by Access Control Service. An AD FS 2.0 identity provider then receives the public key for encryption when it imports the WS-Federation metadata from Access Control Service. For more information, see help on Active Directory Federation Services 2.0.
Consider reading the following resources for more information:
- Certificates and Keys Explained
- How To: Configure Trust Between ACS and ASP.NET Web Applications Using X.509 Certificates
- How To: Configure Trust Between ACS and WCF Service Using Symmetric Keys
Also consider reviewing the following resource focusing on security countermeasures for Windows Identity Foundation (WIF):
- Programming Windows Identity Foundation (Dev - Pro)
- A Guide to Claims-Based Identity and Access Control (Patterns & Practices) – free online version
- Developing More-Secure Microsoft ASP.NET 2.0 Applications (Pro Developer)
- Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server
- Advanced .NET Debugging
- Debugging Microsoft .NET 2.0 Applications
- ACS Error Codes
- Windows Identity Foundation (WIF) and Azure AppFabric Access Control (ACS) Service Survival Guide
- Videos: Windows Azure Security Essentials For Decision Makers, Security Architecture, Access, and Secure Development
- Video: What’s Windows Azure AppFabric Access Control Service (ACS) v2?
- Video: What Windows Azure AppFabric Access Control Service (ACS) v2 Can Do For Me?
- Video: Windows Azure AppFabric Access Control Service (ACS) v2 Key Components and Architecture
- Video: Windows Azure AppFabric Access Control Service (ACS) v2 Prerequisites