Migrate from the Azure Access Control service
Azure Access Control, a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. Applications and services that currently use Access Control must be fully migrated to a different authentication mechanism by then. This article describes recommendations for current customers, as you plan to deprecate your use of Access Control. If you don't currently use Access Control, you don't need to take any action.
Overview
Access Control is a cloud authentication service that offers an easy way to authenticate and authorize users for access to your web applications and services. It allows many features of authentication and authorization to be factored out of your code. Access Control is primarily used by developers and architects of Microsoft .NET clients, ASP.NET web applications, and Windows Communication Foundation (WCF) web services.
Use cases for Access Control can be broken down into three main categories:
- Authenticating to certain Microsoft cloud services, including Azure Service Bus and Dynamics CRM. Client applications obtain tokens from Access Control to authenticate to these services to perform various actions.
- Adding authentication to web applications, both custom and prepackaged (like SharePoint). By using Access Control "passive" authentication, web applications can support sign-in with a Microsoft account (formerly Live ID), and with accounts from Google, Facebook, Yahoo, Azure AD, and Active Directory Federation Services (AD FS).
- Securing custom web services with tokens issued by Access Control. By using "active" authentication, web services can ensure that they allow access only to known clients that have authenticated with Access Control.
Each of these use cases and their recommended migration strategies are discussed in the following sections.
Warning
In most cases, significant code changes are required to migrate existing apps and services to newer technologies. We recommend that you immediately begin planning and executing your migration to avoid any potential outages or downtime.
Access Control has the following components:
- A secure token service (STS), which receives authentication requests and issues security tokens in return.
- The Azure classic portal, where you create, delete, and enable and disable Access Control namespaces.
- A separate Access Control management portal, where you customize and configure Access Control namespaces.
- A management service, which you can use to automate the functions of the portals.
- A token transformation rule engine, which you can use to define complex logic to manipulate the output format of tokens that Access Control issues.
To use these components, you must create one or more Access Control namespaces. A namespace is a dedicated instance of Access Control that your applications and services communicate with. A namespace is isolated from all other Access Control customers. Other Access Control customers use their own namespaces. A namespace in Access Control has a dedicated URL that looks like this:
https://<mynamespace>.accesscontrol.windows.net
All communication with the STS and management operations are done at this URL. You use different paths for different purposes. To determine whether your applications or services use Access Control, monitor for any traffic to https://
The exception to this is any traffic to For more information about Access Control, see Access Control Service 2.0 (archived). As of November 2017, all Access Control components are fully supported and operational. The only restriction is that you can't create new Access Control namespaces via the Azure classic portal. Here's the schedule for deprecating Access Control components: The following sections describe high-level recommendations for migrating from Access Control to other Microsoft technologies. Each Microsoft cloud service that accepts tokens that are issued by Access Control now supports at least one alternate form of authentication. The correct authentication mechanism varies for each service. We recommend that you refer to the specific documentation for each service for official guidance. For convenience, each set of documentation is provided here: SharePoint 2013, 2016, and SharePoint Online customers have long used ACS for authentication purposes in cloud, on-prem, and hybrid scenarios. Some SharePoint features and use cases will be affected by ACS retirement, while others will not. The below table summarizes migration guidance for some of the most popular SharePoint feature that leverage ACS: For web applications that use Access Control for user authentication, Access Control provides the following features and capabilities to web application developers and architects: Unfortunately, there isn't one service that offers all of these equivalent capabilities. You should evaluate which capabilities of Access Control you need, and then choose between using Azure Active Directory, Azure Active Directory B2C (Azure AD B2C), or another cloud authentication service. A path to consider is integrating your apps and services directly with Azure AD. Azure AD is the cloud-based identity provider for Microsoft work or school accounts. Azure AD is the identity provider for Office 365, Azure, and much more. It provides similar federated authentication capabilities to Access Control, but doesn't support all Access Control features. The primary example is federation with social identity providers, such as Facebook, Google, and Yahoo. If your users sign in with these types of credentials, Azure AD is not the solution for you. Azure AD also doesn't necessarily support the exact same authentication protocols as Access Control. For example, although both Access Control and Azure AD support OAuth, there are subtle differences between each implementation. Different implementations require you to modify code as part of a migration. However, Azure AD does provide several potential advantages to Access Control customers. It natively supports Microsoft work or school accounts hosted in the cloud, which are commonly used by Access Control customers. An Azure AD tenant can also be federated to one or more instances of on-premises Active Directory via AD FS. This way, your app can authenticate cloud-based users and users that are hosted on-premises. It also supports the WS-Federation protocol, which makes it relatively straightforward to integrate with a web application by using WIF. The following table compares the features of Access Control that are relevant to web applications with those features that are available in Azure AD. At a high level, Azure Active Directory is probably the best choice for your migration if you let users sign in only with their Microsoft work or school accounts. If you decide that Azure AD is the best migration path for your applications and services, you should be aware of two ways to integrate your app with Azure AD. To use WS-Federation or WIF to integrate with Azure AD, we recommend following the approach described in Configure federated single sign-on for a non-gallery application. The article refers to configuring Azure AD for SAML-based single sign-on, but also works for configuring WS-Federation. Following this approach requires an Azure AD Premium license. This approach has two advantages: Note This approach requires an Azure AD Premium license. If you are an Access Control customer and you require a premium license for setting up single-sign on for an application, contact us. We'll be happy to provide developer licenses for you to use. An alternative approach is to follow this code sample, which gives slightly different instructions for setting up WS-Federation. This code sample does not use WIF, but rather, the ASP.NET 4.5 OWIN middleware. However, the instructions for app registration are valid for apps using WIF, and don't require an Azure AD Premium license. If you choose this approach, you need to understand signing key rollover in Azure AD. This approach uses the Azure AD global signing key to issue tokens. By default, WIF does not automatically refresh signing keys. When Azure AD rotates its global signing keys, your WIF implementation needs to be prepared to accept the changes. If you can integrate with Azure AD via the OpenID Connect or OAuth protocols, we recommend doing so. We have extensive documentation and guidance about how to integrate Azure AD into your web application available in our Azure AD developer guide. The other migration path to consider is Azure AD B2C. Azure AD B2C is a cloud authentication service that, like Access Control, allows developers to outsource their authentication and identity management logic to a cloud service. It's a paid service (with free and premium tiers) that is designed for consumer-facing applications that might have up to millions of active users. Like Access Control, one of the most attractive features of Azure AD B2C is that it supports many different types of accounts. With Azure AD B2C, you can sign in users by using their Microsoft account, or Facebook, Google, LinkedIn, GitHub, or Yahoo accounts, and more. Azure AD B2C also supports "local accounts," or username and passwords that users create specifically for your application. Azure AD B2C also provides rich extensibility that you can use to customize your sign-in flows. However, Azure AD B2C doesn't support the breadth of authentication protocols and token formats that Access Control customers might require. You also can't use Azure AD B2C to get tokens and query for additional information about the user from the identity provider, Microsoft or otherwise. The following table compares the features of Access Control that are relevant to web applications with those that are available in Azure AD B2C. At a high level, Azure AD B2C is probably the right choice for your migration if your application is consumer facing, or if it supports many different types of accounts. If you decide that Azure AD B2C is the best migration path for your applications and services, begin with the following resources: In some cases, you might find that Azure AD and Azure AD B2C aren't sufficient to replace Access Control in your web applications without making major code changes. Some common examples might include: In these cases, you might want to consider migrating your web application to another cloud authentication service. We recommend exploring the following options. Each of the following options offer capabilities similar to Access Control: Our aim in working with Ping Identity and Auth0 is to ensure that all Access Control customers have a migration path for their apps and services that minimizes the amount of work required to move from Access Control. For web services that are secured with tokens issued by Access Control, Access Control offers the following features and capabilities: Service identities in Access Control are typically used to implement server-to-server authentication. Our recommendation for this type of authentication flow is to migrate to Azure Active Directory. Azure AD is the cloud-based identity provider for Microsoft work or school accounts. Azure AD is the identity provider for Office 365, Azure, and much more. You can also use Azure AD for server-to-server authentication by using the Azure AD implementation of the OAuth client credentials grant. The following table compares the capabilities of Access Control in server-to-server authentication with those that are available in Azure AD. For guidance about implementing server-to-server scenarios, see the following resources: In some cases, you might find that the Azure AD client credentials and the OAuth grant implementation aren't sufficient to replace Access Control in your architecture without major code changes. Some common examples might include: In these cases, you might consider migrating your web application to another cloud authentication service. We recommend exploring the following options. Each of the following options offer capabilities similar to Access Control: Our aim in working with Ping Identity and Auth0 is to ensure that all Access Control customers have a migration path for their apps and services that minimizes the amount of work required to move from Access Control. We understand that many Access Control customers won't find a clear migration path after reading this article. You might need some assistance or guidance in determining the right plan. If you would like to discuss your migration scenarios and questions, please leave a comment on this page.https://accounts.accesscontrol.windows.net
. Traffic to this URL is already handled by a different service and is not affected by the Access Control deprecation. Retirement schedule
http://manage.windowsazure.com?restoreClassic=true
. Use this URl to view your existing namespaces, enable and disable namespaces, and to delete namespaces, if you choose to.https://\<namespace\>.accesscontrol.windows.net
. All other components of Access Control continue to operate normally.Migration strategies
Clients of Microsoft cloud services
Service
Guidance
Azure Service Bus
Migrate to shared access signatures
Azure Service Bus Relay
Migrate to shared access signatures
Azure Managed Cache
Migrate to Azure Redis Cache
Azure DataMarket
Migrate to the Cognitive Services APIs
BizTalk Services
Migrate to the Logic Apps feature of Azure App Service
Azure Media Services
Migrate to Azure AD authentication
Azure Backup
Upgrade the Azure Backup agent
SharePoint customers
Feature
Guidance
Authenticating users from Azure AD
Previously, Azure AD did not support SAML 1.1 tokens required by SharePoint for authentication, and ACS was used as an intermediary that made SharePoint compatibile with Azure AD token formats. Now, you can connect SharePoint directly to Azure AD using token issuance policies.
App authentication & server-to-server authentication in SharePoint on-prem
Not affected by ACS retirement; no changes necessary.
Low trust authorization for SharePoint add-ins (provider hosted and SharePoint hosted)
Not affected by ACS retirement; no changes necessary.
SharePoint cloud hybrid search
Not affected by ACS retirement; no changes necessary.
Web applications that use passive authentication
Migrate to Azure Active Directory
Capability
Access Control support
Azure AD support
Types of accounts
Microsoft work or school accounts
Supported
Supported
Accounts from Windows Server Active Directory and AD FS
- Supported via federation with an Azure AD tenant
- Supported via direct federation with AD FSOnly supported via federation with an Azure AD tenant
Accounts from other enterprise identity management systems
- Possible via federation with an Azure AD tenant
- Supported via direct federationPossible via federation with an Azure AD tenant
Microsoft accounts for personal use
Supported
Supported via the Azure AD v2.0 OAuth protocol, but not over any other protocols
Facebook, Google, Yahoo accounts
Supported
Not supported whatsoever
Protocols and SDK compatibility
WIF
Supported
Supported, but limited instructions are available
WS-Federation
Supported
Supported
OAuth 2.0
Support for Draft 13
Support for RFC 6749, the most modern specification
WS-Trust
Supported
Not supported
Token formats
JWT
Supported In Beta
Supported
SAML 1.1
Supported
Preview
SAML 2.0
Supported
Supported
SWT
Supported
Not supported
Customizations
Customizable home realm discovery/account-picking UI
Downloadable code that can be incorporated into apps
Not supported
Upload custom token-signing certificates
Supported
Supported
Customize claims in tokens
- Pass through input claims from identity providers
- Get access token from identity provider as a claim
- Issue output claims based on values of input claims
- Issue output claims with constant values- Cannot pass through claims from federated identity providers
- Cannot get access token from identity provider as a claim
- Cannot issue output claims based on values of input claims
- Can issue output claims with constant values
- Can issue output claims based on properties of users synced to Azure AD
Automation
Automate configuration and management tasks
Supported via Access Control Management Service
Supported via Microsoft Graph and Azure AD Graph API
Migrate to Azure Active Directory B2C
Capability
Access Control support
Azure AD B2C support
Types of accounts
Microsoft work or school accounts
Supported
Supported via custom policies
Accounts from Windows Server Active Directory and AD FS
Supported via direct federation with AD FS
Supported via SAML federation by using custom policies
Accounts from other enterprise identity management systems
Supported via direct federation through WS-Federation
Supported via SAML federation by using custom policies
Microsoft accounts for personal use
Supported
Supported
Facebook, Google, Yahoo accounts
Supported
Facebook and Google supported natively, Yahoo supported via OpenID Connect federation by using custom policies
Protocols and SDK compatibility
Windows Identity Foundation (WIF)
Supported
Not supported
WS-Federation
Supported
Not supported
OAuth 2.0
Support for Draft 13
Support for RFC 6749, the most modern specification
WS-Trust
Supported
Not supported
Token formats
JWT
Supported In Beta
Supported
SAML 1.1
Supported
Not supported
SAML 2.0
Supported
Not supported
SWT
Supported
Not supported
Customizations
Customizable home realm discovery/account-picking UI
Downloadable code that can be incorporated into apps
Fully customizable UI via custom CSS
Upload custom token-signing certificates
Supported
Custom signing keys, not certificates, supported via custom policies
Customize claims in tokens
- Pass through input claims from identity providers
- Get access token from identity provider as a claim
- Issue output claims based on values of input claims
- Issue output claims with constant values- Can pass through claims from identity providers; custom policies required for some claims
- Cannot get access token from identity provider as a claim
- Can issue output claims based on values of input claims via custom policies
- Can issue output claims with constant values via custom policies
Automation
Automate configuration and management tasks
Supported via Access Control Management Service
- Creation of users allowed via Azure AD Graph API
- Cannot create B2C tenants, applications, or policies programmaticallyMigrate to Ping Identity or Auth0
Auth0 is a flexible cloud identity service that has created high-level migration guidance for customers of Access Control, and supports nearly every feature that ACS does.
Ping Identity offers two solutions similar to ACS. PingOne is a cloud identity service that supports many of the same features as ACS, and PingFederate is a similar on-prem identity product that offers more flexibility. Refer to Ping's ACS retirement guidance for more details on using these products.
Web services that use active authentication
Migrate to Azure Active Directory
Capability
Access Control support
Azure AD support
How to register a web service
Create a relying party in the Access Control management portal
Create an Azure AD web application in the Azure portal
How to register a client
Create a service identity in Access Control management portal
Create another Azure AD web application in the Azure portal
Protocol used
- OAuth WRAP protocol
- OAuth 2.0 Draft 13 client credentials grantOAuth 2.0 client credentials grant
Client authentication methods
- Simple password
- Signed SWT
- SAML token from a federated identity provider- Simple password
- Signed JWT
Token formats
- JWT
- SAML 1.1
- SAML 2.0
- SWTJWT only
Token transformation
- Add custom claims
- Simple if-then claim issuance logicAdd custom claims
Automate configuration and management tasks
Supported via Access Control Management Service
Supported via Microsoft Graph and Azure AD Graph API
Migrate to Ping Identity or Auth0
Auth0 is a flexible cloud identity service that has created high-level migration guidance for customers of Access Control, and supports nearly every feature that ACS does.
Ping Identity offers two solutions similar to ACS. PingOne is a cloud identity service that supports many of the same features as ACS, and PingFederate is a similar on-prem identity product that offers more flexibility. Refer to Ping's ACS retirement guidance for more details on using these products.
Questions, concerns, and feedback