Release Notes

  • Article

Updated: June 19, 2015

Applies To: Azure

This topic describes the new features in each release of Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS), explains how each release of the product differs from its predecessors, and highlights any breaking changes that might affect code written for an earlier release.

  • March 2015 – Migrate ACS Namespaces to Google OpenID Connect

  • June 2014 – Google Identity Provider Support

  • July 2013 Update Release Notes

  • December 2012 Update Release Notes

  • September 2012 Update Release Notes

  • June 2012 Update Release Notes

  • May 2012 Update Release Notes

  • January 2012 Update Release Notes

  • July 2011 Update Release Notes

March 2015 – Migrate ACS Namespaces to Google OpenID Connect

ACS has implemented a feature to help ACS namespace owners migrate their Google identity provider configurations from OpenID 2.0 to OpenID Connect. Customers will have until June 1, 2015 to migrate their ACS namespaces to OpenID Connect and until Jan 1, 2017 to migrate their backend code to use OpenID Connect identifiers. Failure to perform the appropriate action before each deadline will cause disruption to your applications. For detailed guidance, see Migrating ACS Namespaces to Google OpenID Connect.

June 2014 – Google Identity Provider Support

As of May 19, 2014, new ACS namespaces cannot use Google as an identity provider. ACS namespaces that used Google and were registered before May 19, 2014 are unaffected. This new limitation exists because Google is phasing out support for OpenID 2.0, which ACS depends on, and has closed registration for new applications. Existing ACS namespaces that used Google will continue to work until April 20, 2015. If your application requires support for Google accounts, we recommend that you register your application with them directly.

If a user attempts to sign in to a new ACS namespace using their Google account, they will be redirected to an HTTP 400 error page.

New ACS namespace and Google error

July 2013 Update Release Notes

To increase the availability and performance of ACS for all users, ACS has implemented a limit of 30 token requests per second for each namespace. If a namespace exceeds this limit for a prolonged period, ACS rejects token requests from the namespace for the duration of the interval and returns an HTTP 429 / ACS90055 "Too many requests" error. For more information, see ACS Service Limitations and ACS Error Codes.

December 2012 Update Release Notes

New Features

The December 2012 update of ACS includes the following new features:

Support for federated single sign-out using the WS-Federation protocol

Web applications that use ACS to enable single sign-on (SSO) with identity providers using the WS-Federation protocol can now take advantage of single sign out capabilities. When a user signs out of a web application, ACS can automatically sign the user out of the identity provider and out of other relying party applications that use the same identity provider.

This feature is enable for WS-Federation identity providers, including Active Directory Federation Services 2.0 and Windows Live ID (Microsoft account). To enable single sign out, ACS performs the following tasks for WS-Federation protocol endpoints:

  • ACS recognizes wsignoutcleanup1.0 messages from identity providers and responds by sending wsignoutcleanup1.0 messages to relying party applications.

  • ACS recognizes wsignout1.0 and wreply messages from relying party applications and responds by sending wsignout1.0 messages to identity providers and wsignoutcleanup1.0 messages to relying party applications.

For more information, see Code Sample: ASP.NET MVC 4 with Federated Sign-out and Passive Authentication for ASP.NET in WIF.

Discontinue support for ACS 1.0

Support for Access Control Service 1.0 is discontinued in this release, including support for migrating from Access Control Service 1.0 to Access Control Service 2.0.

Navigating to Access Control namespaces in new Azure Management Portal

The new Azure Management Portal (https://manage.WindowsAzure.com) includes a route to the familiar ACS Management portal where you create and manage Access Control namespaces.

To navigate to the ACS Management portal:

  1. Go to the Microsoft Azure Management Portal (https://manage.WindowsAzure.com), sign in, and then click Active Directory. (Troubleshooting tip: "Active Directory" item is missing or not available)

  2. Click an Access Control namespace, and then click Manage.

To create an Access Control namespace, click New, click App Services, click Access Control, and then click Quick Create. (Or, click Access Control Namespaces before clicking New.)

For help with ACS management tasks in the Microsoft Azure Management Portal, click Active Directory, and then click Help (?). (Or, click Active Directory, click Access Control Namespaces, and then click Help.)

Navigating to the Access Control namespace for a service bus

When you create a Service Bus namespace in the , the portal automatically creates an Access Control namespace for the service bus.

To configure and manage the Access Control namespace for a service bus:

  1. Log in to the Azure Management Portal.

  2. Click Service Bus and then select a service bus.

  3. Click Access Key and then click Open ACS Management Portal.

To verify that the Access Control namespace is associated with the service bus, see the Service Namespace field at the top of the Access Control Service page. The namespace name consists of the service bus name with an "-sb" suffix.

For more information, see How to: Manage the Access Control Namespace for a Service Bus.

ACS management portal enhancements for viewing WS-Federation identity provider keys, hiding passwords

This release contains a pair of enhancements related to viewing and working with certificates, keys, and passwords in the ACS 2.0 management portal:

  • Signing certificates are now visible in the Edit WS-Federation Identity Provider section – Previously, certificates imported from WS-Federation metadata used to validate the signature of tokens issued from that identity provider were not visible in the ACS Management portal. The Edit WS-Federation Identity Provider section now displays information about imported certificates, including their expiration dates and status. These certificates can now be refreshed using a new “Reimport data from WS-Federation metadata URL upon save” checkbox.

  • Passwords and symmetric signing keys are now hidden by default – To prevent unintentional disclosure of passwords and symmetric keys, these values are now hidden by default on the Edit screens throughout the portal. To intentionally display the value of a password or symmetric key (for example, so it can be copied into an application), a “Show Password” or “Show Key” button must now be pressed.

Ability to Federate Directory Tenants with Access Control namespaces

Azure Active Directory tenants can now be used as identity providers in Access Control namespaces. This enables many scenarios such as enabling your web application to accept both organizational identities from directory tenants and consumer identities from social providers such as Facebook, Google, Yahoo!, Microsoft accounts or any other OpenID provider. You can find detailed instructions on how to implement the scenario in this post, Provisioning an Azure Active Directory Tenant as an Identity Provider in an ACS Namespace.

SAML 2.0 Protocol Support for Relying Party Applications (Developer Preview)

ACS now supports the SAML 2.0 protocol for issuing tokens to relying party applications. SAML 2.0 protocol support has been released as a developer preview, meaning that details of the SAML 2.0 protocol implementation are still subject to change. For more details, seeDeveloper Preview: SAMLProtocol.

Known Issues

In the December 2012, Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) update, the following known issues have been identified:

Azure Co-Administrators can now manage Access Control namespaces. However, an action is required to propagate pre-existing co-administrators to a pre-existing Access Control namespaces.

Prior to the November 2012 update, we resolved an issue where, by default, only the primary Azure service administrator could manage Access Control namespaces created in the subscription. If an Azure co-administrator attempted to access the ACS Management Portal for an Access Control namespace, they would receive one of the following ACS error codes:

  • ACS50000: There was an error issuing a token.

  • ACS60000: An error occurred while processing rules for relying party using issuer ‘uri:WindowsLiveID’

  • ACS60001: No output claims were generated during rules processing.

This issue is now resolved for new Access Control namespaces created by any Azure service administrator or co-administrator. However, customers with namespaces that existed prior to the fix need to perform the following workaround for co-administrator data to propagate to those namespaces:

  1. Sign in to the Azure portal (https://windows.azure.com/) using service administrator or account administrator credentials.

  2. Remove and re-add the co-administrator, using the guidance in How to Add and Remove Co-Administrators for Your Azure Subscriptions (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

  3. Sign out and sign in to the Azure portal using the co-administrator credentials. You will then be able to manage the Access Control namespaces.

September 2012 Update Release Notes

In September 2012, Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) received an update that contained the following changes:

The entityID published in the WS-Federation metadata emitted by ACS is now consistently lowercase

The “entityID” attribute in the WS-Federation metadata published by Access Control namespaces is now always lowercase. In previous releases, it used the letter case that was entered when the namespace was created in the Azure portal. The “entityID” attribute identifies the Access Control namespace to relying party applications, and below is an example of the attribute:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

This change was required to address potential token validation issues in which the letter-case of the Access Control namespace in the ACS -issued token (which is always lower case) does not match the letter-case of the Access Control namespace imported by the relying party. Relying parties that use Windows Identity Foundation are not affected by the case-sensitivity issues.

X.509 Certificates uploaded to ACS now have a public key size restriction of 4096 bits

All X.509 certificates uploaded to an Access Control namespace via the ACS management portal or management service are now required to have a public key size that is no greater than 4096 bits. This includes certificates used for token signing, token encryption, and token decryption.

In Windows, the public key size of a certificate can be checked by opening the certificate (.CER) file, selecting the “Details” tab, and checking the value of the “Public key” field. Certificates that use the secure sha256RSA signature algorithm will have a 2048 bit public key.

Any existing certificates that have a key size of greater than 4096 bits will continue to work with ACS, but these certificates cannot be resaved in ACS until they are replaced with a compliant certificate.

Minor change to “primary key” selection algorithm that is used when ACS signs a token using an X.509 certificate

In the ACS management portal and management service, there is a “Make Primary” field for token signing certificates that, when selected, causes ACS to sign tokens using that certificate. With this release, if no configured token signing certificates have the “Make Primary” field checked, the Access Control namespace will use the existing non-primary token signing certificate that has the earliest valid start date to sign the token. ACS still does not sign tokens with a non-primary token signing certificate if a primary certificate exists, but is invalid or is expired.

JWT Beta: Change in signing behavior when using a global namespace certificate or key to sign a JWT token

When beta support for the JSON Web Token (JWT) format was released in June 2012, ACS used the following order of precedence to determine what key should be used to sign each JWT token issued to each relying party application:

  • Symmetric signing key assigned to relying party, if available

  • X.509 signing certificate assigned to relying party, if available

  • Symmetric signing key assigned to the Access Control namespace

  • X.509 signing certificate assigned to the Access Control namespace

As of this release, namespace-wide symmetric keys are no longer supported for signing JWT tokens. Below is the new order of precedence for signing JWT tokens:

  • Symmetric signing key assigned to relying party, if available

  • X.509 signing certificate assigned to relying party, if available

  • X.509 signing certificate assigned to the Access Control namespace

June 2012 Update Release Notes

In June 2012, ACS received an update that contained the following new feature:

JWT format now available for relying party applications (Beta)

This update introduces support for the JSON Web Token (JWT) BETA format in ACS. JWT is a lightweight, JSON-encoded token format that can be signed using an X.509 certificate or symmetric key, and can be issued by ACS to relying party applications over any of the following protocols:

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

The JWT token format is now a selectable option in the Relying Party Applications section of the ACS Management Portal, and is also configurable through the ACS Management Service.

To learn more about the JWT token format, see the JSON Web Token specification. ACS code samples that feature JWT tokens will be forthcoming at a future date.

Important

JWT support is marked as “Beta” in ACS, which means that all details of the JWT implementation are subject to change. Developers are encouraged to experiment with this token format. However, JWT should not be used in production services, since the behavior may change without notice.

May 2012 Update Release Notes

In early May, 2012, ACS received an update that contained the following change:

Changes to entity ID properties exposed via management service

The ACS Management Service currently exposes an ID property for each of the entity types it supports, as described in the ACS Management Service API Reference. These ID properties are automatically set and managed by ACS.

In this service update, ACS is being migrated to a different database schema, and as a result these IDs exposed via the management service will change for all entity types.

It is uncommon and generally not recommended that applications store or take a hardcoded dependency these IDs in order to query specific entities via the management service. Instead, it is recommended that RelyingParty, ServiceIdentity, RuleGroup, and Issuer entity types be queried using the Name property, and other entity types be queried using a parent entity ID (e.g. RuleGroupId in the case of rules, or IssuerId in the case of identity providers).

Changes to database collation for rules processing

In order to expand support for international languages and to improve security, this release of ACS updates the underlying SQL database collation used to compare input claims from SQL_Latin1_General_CP1_CI_AS to Latin1_General_100_BIN2. This change allows ACS to support additional character sets and combinations of character sets. Applications relying on input claims containing strings with multiple character sets, not supported by SQL_Latin1_General_CP1_CI_AS may see different or additional claims as a result of this new collation. Customers wishing to take advantage of this new capability are encouraged to validate their applications for compatibility with the new SQL collation.

January 2012 Update Release Notes

On January 25th, 2012, ACS 2.0 received an update that contained the following changes:

  • Change in ACS error responses for failed authentication requests

  • Change in OAuth 2.0 error codes for failed authentication requests

Change in ACS error responses for failed authentication requests

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:

Authentication Response Before After

Non-existent Issuer

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, OR

ACS50012 AuthenticationFailed

Incorrect Credentials

ACS50006 InvalidSignature

Change in OAuth 2.0 error codes for failed authentication requests

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:

Authentication Response Examples Before After

Non-existent Issuer

invalid_client

invalid_client

Incorrect Credentials

SWT is signed with an incorrect key.Client id and credentials do match those configured in ACS.

invalid_grant

Authentication Failed

Audience URI validation failed.Certificate validation failed.Assertion from a Service Identity contains self-issued claims.

invalid_grant

Malformed Assertion

Signature is missing from SWT.SAML assertion is not valid XML.

invalid_request

Authorization Code Malformed

invalid_grant

invalid_grant

Authorization Code Invalid

invalid_grant

Malformed OAuth2 Request

invalid_request

invalid_request

July 2011 Update Release Notes

The release notes for the July 2011 update of ACS 2.0 contains the following items:

  • Prerequisites

  • New Features

  • Changes

  • Known Issues

  • Known Issues

Prerequisites

All Access Control 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.

New Features

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, Portuguese (Brazil), 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.

Changes

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.

Known Issues

The following is a known issue in this release:

Rule editor cannot display custom issuers that are not associated with identity providers

Currently, the rule editor in the ACS Management Portal can only display claim issuers that are associated with an identity provider or ACS. If a rule is loaded that references an issuer that does not correspond to either of these things, then the following error will be displayed:

  • ACS80001: This rule is configured to use a Claim Issuer type that is not supported by the management portal. Please use the management service to view and edit this rule.

There are two supported scenarios where an issuer can exist without an associated identity provider in ACS:

  • In an OAuth 2.0 delegation scenario, an issuer record is created in the Access Control namespace by using the ACS Management Service, and this issuer does not have an associated identity provider.

  • When an issuer is created for the purpose of asserting claims in a token request over the OAuth WRAP protocol, while using an identically-named service identity to authenticate with ACS.

Quotas

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 Access Control namespace.

Service Limitations

For more information about service limitations, see ACS Service Limitations.