Release Notes

In the previous release, ACS responded with different error codes when a client authenticated with a non-existent issuer (error code: ACS50026) or incorrect credentials (error code: ACS50006). These error codes were previously emitted when a client attempted to authenticate using an invalid service identity name, or using a SWT or SAML token issued from an invalid identity provider.

ACS will return error codes ACS50008, ACS50009 or ACS50012 for a failed authentication in the cases of SWT, SAML and username/password, respectively. See the table below for details:

Also in the previous release, ACS responded with different OAuth 2.0 error codes when a client authenticated with a non-existent issuer (invalid_client) or incorrect credentials (invalid_grant). This behavior has also been updated, and ACS will return invalid_request when the OAuth 2.0 request is malformed, invalid_client if the client fails authentication or the assertion provided for authentication is malformed or invalid, and invalid_grant if the authorization code is malformed or invalid. See the table below for details:

All ACS namespaces automatically receive the July 2011 update. This update contains no changes to the ACS prerequisites for new or existing customers. For more information on the current ACS prerequisites, see ACS Prerequisites.

The July 2011 update to ACS contains the following new features:

1. Rules now support up to two input claims

The ACS rules engine now supports a new type of rule that allows up to two input claims to be configured, instead of only one input claim. Rules with two input claims can be used to reduce the overall number of rules required to perform complex user authorization functions.

In the ACS Management Portal, a second input claim can be specified in a new rule by clicking Add a second input claim in the rule editor. In the management service, rules with two input claims can be configured using the ConditionalRule entity type. Rules with one input claim are still configured using the Rule entity type for backwards compatibility.

For more information on rules with two input claims, see Rule Groups and Rules.

2. Localization in eleven languages

The ACS Management Portal and the ACS-hosted login page for relying party applications now support localization in eleven written languages, including English, French, German, Italian, Japanese, Korean, Russian, Spanish, Brazilian Portuguese, Simplified Chinese, and Traditional Chinese. An “English (International)” option is also available that uses an alternate date format for setting and displaying effective/expiration dates for keys. The written language displayed for these user interfaces can be changed in one of the following three ways:

• Language Selector – In the ACS Management Portal, the displayed language can be instantly changed using a new language selector menu that appears in the upper-right corner of the portal.
  
  
• URL – The language displayed in the ACS Management Portal can be changed by adding a “lang” parameter to the end of the request URL. The legal values for this parameter are ISO 639-1/3166 language codes that correspond to a supported language. Examples values include en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn, and zh-tw. Below is an example ACS Management Portal URL with a parameter setting the displayed language to French:
  
  https://your-namespace.accesscontrol.windows.net/?lang=fr
  
  
• Web Browser Preferences – If the “lang” URL parameter or language selector has never been used to set a language preference, then the ACS Management Portal and ACS-hosted login pages will determine the default language to display based on the language preferences set in the web browser settings.
  
  

The following are notable service behavior changes in this release:

1. Encoding is now UTF-8 for all OAuth 2.0 responses

In the initial release of ACS, the character encoding set for all HTTP responses from the OAuth 2.0 endpoint was US-ASCII. In the July 2011 update, the character encoding of all HTTP responses is now set to UTF-8 to support extended character sets.

The following are known issues in this release:

1. Only one Windows Azure Portal administrator can access the ACS management portal by default

When an ACS namespace is created in the Windows Azure Portal, only the primary service administrator can manage it by default. A primary service administrator account is created when the Windows Azure subscription is initially set up. If Windows Azure co-administrators try to access the ACS Management Portal for a namespace, they will receive the following error messages:

• ACS50000: There was an error issuing a token.
  
  
• ACS60000: An error occurred while processing rules for relying party using identity provider 'uri:WindowsLiveID'.
  
  
• ACS60001: No output claims were generated during rules processing.
  
  

To work around this issue, perform the following procedure:

2. Rule editor cannot display issuers used for OAuth 2.0 delegation

In an OAuth 2.0 delegation scenario (as presented in Code Sample: OAuth 2.0 Delegation), an issuer record is created in the ACS namespace using the ACS Management Service, and this issuer does not have an associated identity provider. The rule editor in the ACS Management Portal is currently not able to display this issuer, and instead shows an error. To work around this issue, rules can be edited using the ACS Management Service when using OAuth 2.0 delegation.

As of this release, ACS does not impose limits on the number of identity providers, relying party applications, rule groups, rules, service identities, claim types, delegation records, issuers, keys, and addresses that can be created for a given ACS namespace.