This project is read-only.

Release Notes - February 2011 Labs Update

An update was made to the Labs release of Access Control Service on February 28, 2011 that contains the following breaking changes:

Schema changes for OData client

Property name in schema

Type of change


*.SystemReserved [boolean, immutable]


This property has been added to all OData objects, and indicates whether or not an object is reserved for exclusive use by the ACS namespace.

Important: If you are using the ACS management service to programmatically manage ACS, your management service client code must updated and recompiled to function correctly after February 28, 2011. No code changes are required other than recompiling the updated management service client code. 


Known Issues

Below are known issues introduced in the February labs update. These issues have fixes planned for a forthcoming release. 

Requesting an OAuth2 Access token using a Refresh token returns an ACS50000 error
This issue occurs after an OAuth2 access token and refresh token have successfully been issued to a client, and the client uses the refresh token (“grant_type=refresh_token”) to obtain a new access token after the original one expires.

Instead of issuing a new access token, the following error messages are returned:  “ACS50000: There was an error issuing a token. ACS70000: The provided access grant is invalid, expired or revoked.”

Updated: 3/17/2011

 Release Notes - February 2011 Labs Release

The February 9, 2011 Labs release of Access Control Service contains the following changes:

Management Portal Changes

 The ACS management portal has been redesigned to match the look and feel of the new Windows Azure and AppFabric portals. The portal now features a new left-hand navigation menu that provides easy access to all sections of the portal.

Federated Sign Out

 The home realm discovery JSON feed now features a LogoutURL property, which is populated for ADFS and Windows Live ID identity providers. This URL allows end-users to sign out of the ADFS or Windows Live ID identity provider that they signed in with.

Simplified Sign in for Windows Phone 7 Apps

An endpoint has been added to ACS to simplify retrieval of a security token from the website so it can be used in the WP7 app to authenticate to a protected resource.  This endpoint can be used by calling the home realm discovery JSON feed with the protocol set to "javascriptnotify" and using the returned LoginUrl to redirect to the identity provider. 

Known Issues

Below are known issues with some of the new features introduced in the February Labs release. These issues have fixes planned for a forthcoming release.

Launching the ACS portal from the AppFabric portal

In this release, users of the AppFabric portal at may need to disable their web browser’s pop-up blocker in order to launch the ACS management portal. The ACS management portal is launched by selecting “Manage Access Control Service” in the Access Control Service section of the AppFabric portal.


Release Notes - December 2010 Labs Release

The December 2010 Labs release of Access Control Service contains the following changes:

Trust Management Changes

The December release changes how the lifecycles of token signing and token decryption certificates are managed in an Access Control Service namespace. These certificates now support a “Primary” flag, which allows administrators to manually specify which certificate is active at any given time. This allows the effective dates for these certificates and keys to overlap, during which both will be published in the WS-Federation metadata for the service namespace. Relying party applications can subsequently import data about new certificates in advance of a rollover.

In addition, the ACS Management Portal now supports importing WS-Federation metadata for individual relying party applications.

Error Message Changes

The error codes and error messages produced by Access Control Service have been overhauled to provide more troubleshooting details and diagnostics information. This includes errors produced by the various ACS protocol endpoints, as well as the management portal.

In addition, the December release includes a new feature that allows relying party applications to render custom error pages for errors that occur during the end-user sign-in process. This can be configured using a new “Error URL” field that is available when adding and editing relying party applications. When configured, ACS will post information about errors that occur during sign in to this URL, which can be a page hosted on the relying party application that renders a custom error page.

Management Portal Changes

The December release includes the following changes to the ACS Management Portal:

  • The Relying Party Applications section now supports importing application settings using WS-Federation metadata.
  • The Relying Party Applications section now supports setting an “Error URL”, which is the URL error details will be sent when an error occurs during user sign in. If no URL is provided, a page hosted by ACS will display the error information.
  • In the “Certificates and Keys” section, Token Signing and Token Decryption certificates and keys now support a “Primary” flag which determines whether or not they are actively in use.
  • A new “Portal Administrators” section allows new ACS administrators to be configured without requiring manual edits to the Access Control Management relying party application and rule group.
  • The “Management Credentials” section has been replaced with a “Management Service” section that allows multiple management service accounts to be created.
  • The Access Control Management relying party application and rule group are now hidden in the management portal. These are now configured in the portal using the new “Portal Administrators” and “Management Service” sections, however they are still directly accessibly via the management service.
  • Display names for passwords, symmetric keys, and certificates have been deprecated.

Management Service Changes

The December release includes the following breaking changes to the ACS Management Service:

  • Federation Metadata address for importing the IdentityProviders was updated from “/v2/mgmt/service/importFederationMetadata” to “/v2/mgmt/service/importFederationMetadata/importIdentityProvider”
  • Importing RelyingParties from Federation Metadata is now supported, the address is “/v2/mgmt/service/importFederationMetadata/importRelyingParty” 
  • Policy and PolicyRuleGroup removed 
  • RelyingPartyRuleGroup added 
  • Password property in ServiceKey updated from string to byte[] 
  • InputClaimIssuerId property in Rule renamed to IssuerId 
  • Name property removed from IdentityProvider 
  • Issuer and IssuerID property added to IdentityProvider 
  • ProtocolType property in IdentityProvider renamed to WebSSOProtocolType 

Known Issues

Below are known issues with some of the new features introduced in the December labs release. These issues have fixes planned for a forthcoming release.

  • Namespace does not finish activating if the supplied name is between 45 and 50 characters – When creating an AppFabric namespace, the maximum length for the namespace name is now 44 characters, down from 50 characters in previous releases.  If you attempt to create a namespace with a name whose length is between 45 and 50 characters, an error will not be displayed but the namespace will never finish the activation process. As a workaround, create a namespace whose name contains 44 characters or less. 

  • Issues with importing WS-Federation metadata for a relying party application – There are two issues with importing WS-Federation metadata for a relying party application:

    • WS-Federation metadata currently cannot be imported using a URL, and doing so will result in an unexpected error message. As a workaround, copy the application's WS-Federation metadata to a file, and select the "File" option to upload it instead.

    • WS-Federation metadata will not be imported if the “Token encryption policy” field is set to “Require Encryption” in the relying party application form, as this setting requires a certificate to be uploaded separately. As a workaround, import the WS-Federation metadata with the “Token encryption policy” field is set to “none”. Then, edit the relying party application again to set the “Token encryption policy” field to “Require Encryption”.

  • Secondary token decryption certificatesWhen adding a second token decryption certificate for the service namespace and setting is as “Primary”, the original certificate will incorrectly remain published in the WS-Federation metadata. As a workaround, only use one token decryption certificate in this release. 

  • Facebook and offline_access permissions- When configuring Facebook as an identity provider, end user login to Facebook will fail with a 400 error code if the “offline_access” permission is added in the “Application permissions” field in the management portal. As a workaround, avoid adding the “offline_access” permission.


Release Notes - October 2010 Labs Release

The October 2010 Labs release of Access Control Service contains the following breaking changes:

Default signing certificate and key now available

In the September release, customers were required to add their own certificates and keys to sign tokens issued by Access Control Service. In the October release, a default certificate and a default symmetric key are provisioned when a new service namespace is created. Users no longer need to upload a certificate to sign tokens or access ACS WS-Federation metadata.

Management service credentials

In the September release, the key that was required to access the management service endpoint was represented as a Service Identity. In the October release, this default Service Identity has been removed. A new key type has been added specifically for using the management service, which can be configured using the "Management Credentials" section of the ACS portal. The username required to access the management service has remained unchanged (“ManagementClient”). In OData, these credentials are represented as a new KeyUsage (“Management”) and new KeyType (“Password” or “Symmetric”) in the ServiceKeys Table. 

Claim type change for service identities and Windows Live authentication

Access Control Service will now emit a claim with type “NameIdentifier” for clients authenticated using a service identity or Windows Live. The September release used to emit a “Name” claim type.


Access Control Service now uses the Facebook Graph API to support Facebook as an identity provider.

Visible changes include:

  • Facebook identity provider configuration now requires an Application ID in addition to Application Secret, as opposed to an API Key and Application Secret. Additionally, an Application Permissions field (optional) is now available that allows additional extended permissions to be requested.
  • The session key and session secret claim types are no longer emitted from Facebook identity providers. Instead, an access token claim is generated.
  • The value of the IdentityProvider claim emitted by Access Control Service is now “Facebook-<FacebookApplicationId>” for Facebook identity providers

Endpoint changes

WS-Trust endpoints have been separated based on incoming token key type. The new endpoint paths are:

  • v2/wstrust/13/issuedtoken-asymmetric
  • v2/wstrust/13/issuedtoken-bearer
  • v2/wstrust/13/issuedtoken-symmetric

This change is breaking only for customers that don’t use MEX endpoint to generate clients

Schema changes for OData client

Property name in schema

Type of change


IdentityProvider.LoginParameters [string, optional]


Comma (,) separated list of extended permissions for Facebook. The list of permissions is described at

Delegation.IdentityProvider [string, mandatory]


Value of this property will be used to emit identity provider claim(type is in an OAuth2 delegated access token

Delegation.Scope [string, optional]


Value of this property will be emitted in an OAuth2 delegated access token as Scope claim (type is and in addition to that it will be sent in OAuth2 Access Token response "scope" parameter

ServiceIdentity.RedirectAddress [string,optional]


Value of this property is used only in OAuth2 delegated scenario. This value is verified against the client redeeming AuthorizationCode. Value defined in client "redirect_uri" parameter has to match exactly its own service identity redirect address. This value is mandatory for enabling OAuth2 delegation scenario

Rules. InputClaimValue


Input claim values are now case sensitive

Properties [table]



IdentityProviderKeyNames [table]



RelyingPartyKeyNames [table]



IdentityProvider.CertRevocationCheck [string, optional]



ClaimType.DisplayName [string, optional]



RelyingParty. SymmetricTokenEncryptionRequired [bool, optional]



Rules.RuleType [string, mandatory]





Last edited Mar 17, 2011 at 10:41 PM by asmalser, version 10


No comments yet.