Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News GET Details On Upcoming .Net Access Control Service

GET Details On Upcoming .Net Access Control Service

Leia em Português

This item in japanese

The .net services team, released details on future plans for the .net services offering, that is part of the Azure services platform. .NET Services includes access control to help create secure connections between your applications and services, as well as a service bus for communicating across network and organizational boundaries.

The next Community Technology Preview (CTP) of .NET Services and the supporting Software Development Kit (SDK) is due out in October, and will closely resemble what is planned for our commercial launch. The Microsoft® .NET Service Bus remains largely the same compared to the current CTP, while the Microsoft® .NET Access Control Service will undergo changes in order to bring us closer to locking down the .NET Services launch features.

According to the blog, that RESTful access to the .net services offering is increasingly becoming popular among both, the web developers as well as enterprise developers. The post identifies some of the “gaps” in existing identity solutions especially related to access control.

Today, developers of REST web services lack an easy, accessible means to secure their services. […] Developers face a lack of consistency and common patterns for managing identity and access control in a way that is compatible with REST. As developers move towards REST in 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 in a simple way that integrates well with REST.

What is key is the re-alignment of the offering towards enterprise developers. The post outlines some of the key scenarios that will be enabled in the upcoming release with the aim of capturing a larger developer mindshare.

The.NET Access Control Service provides an easy way to control access to web applications and services while integrating with standards-based identity providers, including enterprise directories and web identity systems such as Windows Live ID. Authorization decisions can be pulled out of the application and put into a set of declarative rules that can transform incoming securing claims into claims that applications understand. 

Some key scenarios that are expected as part of the commercial launch of the access control service are:

  • Two token-exchange endpoints: REST with symmetric key and REST with SAML Extension
  • Claims Transformation Engine: Transform input claims to output claims using configurable rules
  • Security Token Service: Package and transit output claims using REST tokens

The announcement also promises support for access via the WS-* endpoints in the future releases, which will includes scenarios such as web single-sign on, to make the offering holistic.

In concrete terms, this means the WS-* integration features currently supported today will be temporarily unavailable while we focus on delivering a robust infrastructure for REST web services authorization. Once this infrastructure is in place, we will work on future version features of .NET Services, like web single sign-on and rich WS-* support. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the .NET Access Control Service offering in a way that spans the REST/SOAP spectrum.

Kieth Brown from Plural sight weighs in on the announcement.

Those who were expecting to use ACS [access control service] via WS-* or passive fed[eration] immediately at RTM should be rethinking their strategies.

It is certainly interesting that grassroots adoption of cloud services is forcing cloud vendors including Microsoft to rethink the services strategy. We’ve seen google deprecate their WS-* search API in the past. Is this a function of the ease of use and reach of RESTful services that affords the choice of access to these services from myriad platforms and technologies? Or is this a function of scalability of a RESTful services offering as opposed to a WS-* offering? Please visit the the original announcement for complete details and the .NET Services Technical Discussion Forum for providing feedback to the .net services team.

Rate this Article