Dieser Artikel ist Teil 1 einer Serie von 6 Blog-Posts, die die Änderungen der Windows Azure Platform, die diese seit Fertigstellung des Manuskripts zum Buch “Cloud Computing mit der Windows Azure Platform” erfahren hat.

Die 6 Teile sind:
Teil 1: Allgemeine  Änderungen der Windows Azure Platform
Teil 2: Änderungen in Windows Azure
Teil 3: Änderungen der Live Services
Teil 4: Änderungen der .NET Services
Teil 5: Änderungen in SQL Azure
Teil 6: Neue Dienste

Die .NET Services haben mit der Produktivsetzung eine sofort ins Auge fallende Änderung erfahren. Sie wurden umbenannt. Die neue Bezeichnung für diese Dienstgruppe ist Windows Azure Platform AppFabric. Die AppFabric umfasst die beiden Dienste

  • Windows Azure Platform AppFabric Service Bus
  • Windows Azure Platform AppFabric Access Control Service

Im Folgenden werden diese beiden Dienste kurz als Service Bus und Access Control Service bezeichnet. Der Workflow Service wird in zukünftigen Versionen der AppFabric enthalten sein.

An der Positionierung der AppFabric hat sich nichts geändert: Sie umfasst Cloud Services, mit deren Hilfe Entwickler Anwendungen und Dienste, die auf Windows Azure, Windows Server und einer Reihe von anderen Plattformen betrieben werden, verknüpfen. Die Kommunikation kann dabei über den Service Bus abgewickelt und – sofern es sich um REST-basierte Services handelt – Claims-basiert über den Access Control Service abgesichert werden.

Service Bus

Der Service Bus behält seine zentrale Rolle in der Vernetzung verteilter Anwendungskomponenten. Folgende primäre Anwendungsmuster werden unterstützt:

  • Eventing, d.h. der Austausch von Benachrichtigungen zwischen Anwendungen über verschiedene Kommunikationsprotokolle
  • Service Remoting, d.h. das Angebot von lokal beim Anwender (hinter einer Firewall) betriebenen Services in der Cloud
  • Tunneling, d.h. die Kommunikation zwischen Anwendungen über Firewall-Grenzen hinweg

Gegenüber dem Juli-CTP wurde der Funktionsumfang des Service Bus leider in einem entscheidenden Bereich reduziert: Router und Queues wurden aus dem Service Bus entfernt (diese sollen in einem zukünftigen Release mit erweiterten Möglichkeiten wieder verfügbar werden). Entsprechende Abschnitte in diesem Buch sind also zunächst hinfällig.

Im SDK der Produktivversion ist das Beispiel LoadBalance enthalten, das zeigt, wie mit den bestehenden Mitteln des Service Bus eine ähnliche Funktionalität wie die durch Router zuvor bereitgestellte erzielt werden kann.

Die Queues wurden vorübergehend durch Message Buffers ersetzt. Diese bieten einen großen Teil der zuvor von Queues bereitgestellten Funktionalitäten an. Message Buffers sind in den folgenden Bereichen gegenüber Queues eingeschränkt:

  • Ein Message Buffer kann maximal 1 MB Daten enthalten
  • Eine Dequeue-Operation liefert immer nur eine Nachricht zurück
  • Die Overflow-Policy ist auf reject beschränkt
  • Message Buffer sind ausschließlich über REST ansprechbar

Darüber hinaus sind die Konfigurationsmöglichkeiten gegenüber Queues eingeschränkt. Das grundsätzliche Verhalten (»best effort FIFO«) ist allerdings vergleichbar.

Access Control Service

Der Access Control Service (ACS) wurde funktional ebenfalls beschränkt und fokussiert nun auf die Claims-basierte Zugriffskontrolle für REST-basierte Webservices. Vorübergehend wurden also Funktionen für Single-Sign-On oder WS-* Unterstützung aus dem Dienst entfernt und für spätere Releases des ACS angekündigt.

Die Funktionalitäten des ACS umfassen unter anderem folgende Bereiche:

  • Claims-basierte Zugriffskontrolle für REST-basierte Webservices
  • Integrationsmöglichkeit mit ADFS v2
  • Unterstützung von WRAP (= Web Resource Authorization Protocol) und SWT (= Simple Web Token)

Der Prozess zum zugriffsgesicherten Aufruf einer durch ACS geschützten Ressource durch einen Client erfolgt wie in Abbildung 10.3 dargestellt.

BLD10_03

Abbildung 10.3: Claims-basierte Zugriffskontrolle in OAuth Terminologie

Der ACS stellt dem Client also Security Tokens als sogenannte Simple Web Tokens zur Verfügung, das der Client beim Zugriff auf die geschützte Ressource übergeben kann und das diese dann für die Entscheidung über den Zugriff auswerten kann.

Der Client kann drei Arten von Tokens anfordern:

  • Plaintext (einfachste Variante, ohne Verschlüsselung)
  • Signierte Token (HMAC SHA 256 erforderlich)
  • Von AD FS v2 ausgegebene Token, die SAML enthalten (erlaubt Unternehmensintegration)

ACS liefert Tokens immer im SWT-Format zurück. Diese Token haben einen Aufbau ähnlich dem in Listing 10.5 gezeigten Token.

role=Admin%2cUser&
customerName=Contoso%20Corporation&
Issuer=https%3a%2f%2fadatum.accesscontrol.windows.net%2fWRAPv0.8&
Audience=http%3a%2f%2fadatum%2fbillprint&
ExpiresOn=1255912922&
HMACSHA256=yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d

Listing 10.5: Beispiel für das SWT-Format

Ausblick

Microsoft plant, Funktionen, die in der Produktivversion der AppFabric gegenüber früheren CTP-Versionen entfernt wurden, in zukünftigen Releases der Plattform wieder einzuführen. Hierzu gehört beim Service Bus insbesondere die Verfügbarkeit von Routern und Queues.

Für den Access Control Service sind unter anderem folgende Erweiterungen angekündigt:

  • Web Single-Sign-On
  • WS-* Unterstützung (WS-Trust und WS-Federation)
  • Unterstützung verschiedener Web Identity Provider (Live ID, Facebook Connect, Google, Open ID, etc.)
  • Erweiterte Unterstützung von Enterprise Identity Providern
  • Integration von CardSpace

Weitere Informationen