Access Control Service – Roadmap for PDC and Beyond

Статья
09/28/2009

We are in the process of making some key design changes to the Access Control Service (ACS) for our PDC release this fall. I think these changes will bring tremendous benefits to ACS customers in the near-term, but the changes break all ACS-related code that exists today.

This post summarizes the planned changes and provides some guidance for early ACS adopters.

It expands on (and is a bit more unvarnished than) the announcement made here: https://blogs.msdn.com/netservices/archive/2009/09/18/update-on-the-next-microsoft-net-services-ctp.aspx

Summary of Changes

We have decided to focus our efforts on addressing the large, unmet need around access control for REST web services. In concrete terms, this means that the WS-* integration features we support today will be temporarily unavailable while we focus on delivering a robust infrastructure for REST web service authorization. Once this infrastructure is in place, we will work to bring back features like website single sign on and rich WS-* support.

Motivation and Scope

There’s no doubt that Microsoft has made significant, long-term investments in security and identity management using the WS-* protocols: WS-Trust, WS-Federation, WS-Security and others. These protocols are proven and secure, widely adopted by enterprises, and will continue to be a central focus for ACS and other Microsoft groups working on enterprise security and identity management.

At the same time, as REST web services have become very popular with both web and enterprise developers, a gap has emerged in the market place for identity and access control technology. Today, developers of REST web services lack an easy, accessible means to secure their services. They face a lack of consistency and common patterns for managing identity and access control in a way that is compatible with the REST focus on simplicity. As REST developers move towards the enterprise, they will have an increasing need for robust security. They will be required to address the more systematic security concerns of enterprise customers as well as the more complex identity management scenarios that enterprises present. They will need a way to address these requirements that is simple and that integrates well with REST.

Taking this problem as an opportunity to differentiate the ACS offering and serve an even broader range of developers, we have experimented over the past several months with a simplified approach to the way that ACS packages and transits security tokens. Although this simplified approach has been designed to meet the needs of REST web service developers, it will appeal to all developers that want an easy way to take advantage of our services or that wish to use the .NET Services from non-Microsoft platforms.

At MIX09 we exposed some of our thinking about this new approach as a way to gauge customer interest (See JohnShew’s presentation). In addition to talking about our goals for simplicity and broad interoperability, we demonstrated the ability to control access to SaaS web sites using a variety of different consumer identities. Consistent with our theme, we showed that this approach can radically simplify the REST developer experience. Response to the MIX09 presentations was overwhelmingly positive and confirmed our sense that we were on the right track.

From this and other customer feedback, we have come to the conclusion that the lack of tools for controlling access to REST web services is one of the major pain points faced by service developers today. We believe that ACS is well-positioned to address this need in a way that compliments other MSFT offerings in the security and identity management space. The combination of simplicity and support for key enterprise integration scenarios will ensure that ACS appeals to our enterprise customers, while simultaneously meeting the needs of an even broader developer audience. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the ACS offering in a way that spans the REST/SOAP spectrum.

Roadmap

In light of these considerations, we have made significant changes to our product roadmap. The following is a summary of the current ACS roadmap that reflects these changes:

PDC 2009: Simple Web Trust – Authorization for REST Web Services and the Azure Service Bus

Two token exchange endpoints: REST with symmetric key and REST with SAML Extension
REST with symmetric key makes it trivially easy for developers on any platform to package claims for ACS
REST with SAML Extension will work with tokens issued by ADFS V2
Both endpoints will be addressable using standard HTTPs POST requests
ACS will transform input claims to output claims using configurable rules
ACS will package and transit output claims using REST tokens

The Road ahead: Authorization for Web Sites and WS-* Support

New feature development post-PDC will be organized into two streams.

Single Sign On and Authorization for Web Sites

Web sites can automatically redirect users to ACS for authentication and authorization
ACS will broker the authentication process with external identity providers, process resulting claims and return the user to the originating web site with the claims issued by ACS
Web sites can allow users to login using a broad range of existing consumer or corporate identities
Integrates with ADFS V2 and other directories that support WS-Federation Passive or OpenID

WS-* Support

Web services and web sites can take advantage of enhanced security and integration capabilities offered by WS-Trust and WS-Federation
Support CardSpace

To align with this roadmap and make it possible to efficiently support and extend our release, we have invested in extending the foundations of the ACS platform. As a consequence, we have had to constrain the features that are in scope for PDC and carefully identify the scenarios that we are targeting. The following section describes the two core scenarios that will be supported at PDC.

Target Application Scenarios

Both of our target application scenarios involve a SaaS web service that uses ACS to manage access to its on-line resources. In the following scenario descriptions, we will use Northwind Traders (NWT) as the emblematic ACS customer, and Fabrikam Flower Shop and Contoso Auto Corp as emblematic NWT customers. Fabrikam Flowers and Contoso Auto Corp have different needs and capabilities when it comes to integration with NWT’s access control architecture. ACS will enable NWT to serve them both.

Northwind Traders

Northwind Traders (NWT) is an ISV currently working on porting their on-premise software offering to a SaaS offering. Their SaaS offering consists of a REST programmatic endpoint and a website. NWT has decided to use ACS to protect their programmatic endpoint. Concretely, this means that a NWT customer application must first acquire a token from ACS before using the NWT REST service.

Fabrikam Flower Shop

Fabrikam Flowers is a micro-company that sells and delivers flowers. They have four employees and no IT department. They have, however, hired a local person to help them with their local network and to build their basic e-commerce website. Fabrikam Flowers has recently realized that they need to more closely track orders. JBM hears about NWT and their SaaS offering and decides to buy. After reading the NWT documentation, the website developer realizes that the integration is very simple.

Contoso Auto Corp

Contoso Auto Corp designs, builds, distributes, and sells automobiles. They have tens of thousands of employees and a sophisticated IT department. Contoso Auto Corp is in the processs of revamping their selling process. As a result, they need to acquire new sales software. NWT’s new SaaS offering happens to meet Contoso Auto Corp’s requirements, so Contoso Auto Corp decides to proceed with a proof of concept with NWT. Contoso Auto Corp requires that the NWT programmatic endpoint can work with an identity that Contoso Auto Corp owns. Since Contoso Auto Corp uses Active Directory, the Contoso Auto Corp application that integrates with NWT must be able to gain access to NWT using a SAML token generated by ADFS V2. Contoso Auto Corp has developers that understand ADFS and SAML technologies. In order for the NWT proof of concept to succeed, Contoso Auto Corp developers will need to quickly integrate NWT into the Contoso Auto Corp application.

ACS Value Propositions

1. By writing a small amount of code in whatever language it wishes to use, NWT can offload to ACS the cost and complexity of integrating with various customer identity models and technologies.

2. NWT’s customers will benefit from ACS documentation, samples and developer community in integrating their applications with NWT – thus further lowering NWT’s support costs for customer on-boarding.

3. By adopting ACS, NWT will gain access to a number of advanced features, including:

a. Role-based access control

b. Simple delegation

c. Increased protection from denial-of-service attacks

4. NWT can take advantage of ACS’s scale-out capacity to meet growth in demand or unexpected spikes in load.

5. With little or no change to its code, NWT can stay abreast of the rapid evolution in access control standards and technologies and benefit from new features and capabilities as they are added to ACS.

Generic ACS Interaction Model

In its most generic form, the interaction model for ACS involves three participants: the Requesting Application (Fabrikam Flowers App or Contoso Auto Corp App), the Relying Party (NWT) and ACS. The core pattern among these participants is as follows:

1. The Requesting Application (Fabrikam Flowers App or Contoso Auto Corp App) submits to ACS a security token containing input claims. This “inbound” token bears evidence—in the form of key material—that it was issued by a party (Fabrikam Flowers or Contoso Auto Corp) that the Relying Party (NWT) trusts.

2. ACS processes these claims according to rules configured by NWT (via the ACS portal and/or management API) and resolves output claims.

3. ACS packages these output claims into a new, ACS-issued security token and returns this token to the Requesting Application. We refer to this as the “outbound” token.

ACS Token-Exchange Endpoints

In the PDC release, ACS will expose two endpoints where requesting applications can obtain an ACS-issued security token.

ACS endpoints are optimized for REST and are designed to make it extremely easy for companies like Fabrikam Flowers to integrate with ACS. Companies like Contoso Auto Corp will also have a straight-forward integration path using our REST with SAML Extension, which will support inbound ADFS V2-generated SAML tokens.

ACS will also use REST to transit outbound tokens to the Requesting Application. Customers will find it a trivial matter to work with the outbound tokens that ACS produces, whether that involves consuming them or transforming them into other formats for downstream processing.

PDC 2009 Integration with other MSFT Identity Technologies

Windows Identity Foundation (WIF) and ADFS V2

At PDC there will be community samples that demonstrate how to use WIF and ADFS V2 with ACS. WIF will be used to acquire a SAML token from ADFS V2 and to extract the claims from an ACS-issued token. Note that extracting claims from an ACS-issued token will require custom extensions to WIF.

The WIF and ADFS teams are currently investigating native support for this type of REST token in the future versions of both WIF and ADFS.

Windows LiveID (WLID)

At PDC there will also be a community sample that demonstrates how to use WLID with ACS.

Post-PDC Integration Scenarios

After PDC, ACS will extend to natively support many different identity providers both on the web (e.g. WLID, Google, Yahoo, Open ID, Facebook) and the enterprise (e.g. Forefront Identity Manager, ADFS V2, Tivoli, CA SiteMinder, Oracle Identity Manager, and other WS-* compliant servers).

Additional Comments

We plan on going live with ACS on or before the PDC conference in November 2009. While we know that the changes to our roadmap will cause some customer pain as well as internal retooling, we are confident that they will also set us on the right footing to have a very successful offering at PDC and beyond.

If you have questions or comments about the changes we are making, please don’t hesitate to let me know.

Comments

Anonymous
September 28, 2009

When will this new functionality be available? Only at PDC or when the .NET Services October CTP is released?
Currently, ACS is being used to define the Service Bus access control policy (e.g. "Send" and "Listen" permissions). Will this remain valid in the new model, namely when using SOAP based bindings such as the NetEventRelayBinding?

Anonymous
September 29, 2009
The next release of ACS will include this functionality. ACS is still used as the security mechanism for the service bus (including the SOAP bindings). We are simply putting the token in a SOAP header.
Anonymous
October 13, 2009
Are there any plans to submit this new RESTful API of the ACS to some sort of standards body?
Anonymous
June 20, 2012
How can I implement ACS with On-Premise application? Can anyone guide me on the same. Thanks:)

Поделиться через