Windows Azure platform AppFabric Breaking Changes Pre-Announcement

Windows Azure platform AppFabric Breaking Changes Pre-Announcement

In this Windows Azure platform AppFabric release, there are improvements in stability, scale and performance over the previous CTP. Some of these improvements might require user code modification. Applications built on or that communicate with AppFabric Service Bus and AppFabric Access Control might be affected and need to change accordingly.  

Access Control

WRAP version updated. AppFabric Access Control has been updated to support version 0.9 of the Web Resource Authorization Protocol (WRAP). Support for version WRAP v0.8 has been removed. See the OAuth WRAP WG document for WRAPv0.9.7.2 for full details on this version of WRAP (located at https://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf?gda=dLqVw0QAAABFB7PFAFiVedPtjcqT8uuI_dtfzzpm2dFi8PLv_8ljHRidFvlYqd_ZjmG9h9kh5-pV6u9SiETdg0Q2ffAyHU-dzc4BZkLnSFWX59nr5BxGqA). In addition, the WRAP endpoint name has changed from https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/ to https://servicenamespace.accesscontrol.windows.net/WRAPv0.9/. The WRAPv0.8 endpoint has been removed. 

WRAP Request changes

Token type field. In WRAPv0.8, the requester specified the type of token by providing “wrap_swt=[token]” or “wrap_saml=[token]” in the request. In WRAPv0.9, the user now provides a separate parameter specifying the token type: “wrap_assertion_format=[SWT, SAML]”. See Section 5.2 of the WRAPv0.9.7.2 document referenced above for more details.

Token field. In WRAPv0.9, since the token type is a separate parameter (see above item), the token is provided using the “wrap_assertion=[token]” parameter. See Section 5.2 of the WRAPv0.9.7.2 document for details.

Scope field. In WRAPv0.9, the “applies_to” field name has been changed to “wrap_scope”. See Section 5 of the WRAPv0.9.7.2 document for more details.

WRAP Response changes

Expiration field. In the WRAPv0.9 token, the “wrap_token_expires_in” field name has been changed to “wrap_access_token_expires_in”. See section 5 of the WRAPv0.9.7.2 document.

Body field. In the body of the response from ACS upon a token request, the body was previously “wrap_token=[token body]”. The name has been changed such that the body is now “wrap_access_token=[token body]”. See Section 5 of the WRAPv0.9.7.2 document.

Issuer in the returned token. In the November 2009 CTP, the issuer in the token response was the URI of the endpoint that issued the token. For example, in the November 2009 CTP, if you requested a token from https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/, the issuer in the returned token was https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/. In this release, the issuer in the returned token is not tied to a specific endpoint (in preparation for future support of multiple-endpoint-issuing tokens), so the response returns https://servicenamespace.accesscontrol.windows.net/.

Authorization (auth) header. In WRAPv0.8, the auth header appeared as: Authorization: WRAPv0.8 [token]. In WRAPv0.9, the auth header format is now: Authorization: WRAP access_token=”[token]”. See section 4.2 of the WRAPv0.9.7.2 document.

 

Service Bus

Message Buffers

PeekLock expiration. The determination for when message buffer PeekLocks expire was incorrectly computed. In this release, the PeekLock respects the user configurable timeout value and uses the operation timeout to determine when the PeekLock should expire.

URI in Atom feed. The response to the HTTP request to create a message buffer contains an Atom feed identifying the URI for the buffer head. That URI had contained extra slashes. The response has been corrected in this release and now identifies the buffer head with the correct URI.

Allowing “/” in Delete requests. Attempts to delete a message buffer where the buffer URI was incorrectly specified used to return a 500 error. In this release, such Delete requests will return a 400 Bad Request error.

Creation Errors returned. Message buffer creation sometimes failed silently. In this release, creation errors are returned.

Status code change. Invalid message buffer operations had returned an HTTP status code 500. In this release, status codes in the 400-range (4xx) are returned.

Relay Bindings

Port change. Customers communicating with previous versions of the AppFabric Service Bus through firewalls that restrict outbound traffic had to open ports 808 and 828 for NetOnewayRelayBinding and NetEventRelayBinding communication and 818 and 819 for the other bindings. In this release, the range is specified at 9350-9353 where 9350 and 9351 are used for NetOnewayRelayBinding and NetEventRelayBinding communication and 9352 and 9353 are used for the other bindings.

Oneway errors returned. Initiators (clients) using NetOnewayRelayBinding and NetEventRelayBinding were unable to receive error information in previous CTP releases. In this release, failed channel creation or failed message delivery will return the cause of the error, such as quota exceeded and authorization failure.

Unneeded security mode eliminated. The EndToEndWebHttpSecurityMode had an acceptable value of “TransportCredentialOnly” whose behavior was indistinguishable from the value “None”. In this release, “TransportCredentialOnly” is no longer an allowed value.

URIs and Headers

Case sensitivity introduced. Case insensitive comparisons had been made with SOAP headers, HTTP methods (GET, POST, PUT, etc.) and Access Control claim tokens. In this release, such comparisons are now case sensitive in order to comply with these standards.

ASCII required in URI paths. Users had been allowed to include non-ASCII characters in URI names. In this release, URI path names are restricted to the ASCII character set. The ASCII character limitation does not extent to fragments and query strings, which often represent application-domain-specific information.

Token URI validation. When granting permission to access a URI, comparison between the endpoint URI and the URI specified in the token did not distinguish URI segments. Thus, a token issued for abc/def was held to be valid for abc/def/g (which is correct) as well as abc/defg (which is unwanted behavior). In this release, tokens are valid for child segments of the URI.

Using Access Control

Secure channel required for tokens. Customers had been allowed to transmit messages that contained Access Control tokens in clear text. In this release, attempts to send messages that contain Access Control tokens over non-secure transport channels will fail with an error “Transport security is required to protect the token.”

Token tag change. The previous CTP SDK used <BinarySecret> to wrap the Access Control Simple Web Token. This tag is reserved in WS-Trust for carrying key material. In this release, the tag used to wrap SWT tokens is <BinarySecurityToken>. 

Windows Azure platform AppFabric Team