Der Countdown für die Keyfactor Tech Days läuft - sichern Sie sich noch heute Ihren Platz!

  • Startseite
  • Blog
  • Windows Azure: Cloud-Identitätszugang und Föderation

Windows Azure: Cloud-Identitätszugang und Föderation

Laut dem Online-Artikel von Microsoft bietet Windows Azure ein sicheres, unternehmenstaugliches Identitäts- und Zugriffsmanagement für die Cloud.

  • Windows Azure Active Directory
  • Integration in Ihr lokales aktives Verzeichnis
  • Bieten Sie Zugangskontrolle für Ihre Anwendungen
  • Aufbau sozialer Verbindungen im gesamten Unternehmen
  • Bieten Sie Single Sign-On für Ihre Cloud-Anwendungen
  • Erweiterungen für den vorintegrierten Anwendungszugriff (Vorschau)
    • Windows Azure Mobile Dienste
    • Windows Azure Aktive Authentifizierung (Vorschau)

Gehen wir die folgenden vier Cloud-Identitätszugriffs- und Föderationsszenarien durch, die zeigen, wie die Windows Azure Identity-Technologie Best-Practice-Cloud-Integrationslösungen mit OAuth2 (Authorization Code und Implicit Grant Flows in den Szenarien, Client Credentials mit Windows Azure Access and Control Service) ermöglicht, JWT mit SharePoint Online new App Model und Graph API - nicht im Szenario gezeigt), SAML, WS-Federation (passiv im Szenario und aktiv), Graph API, Mobile und Web App, REST, ADFS, Office365, Social Identity Providers, App API von Drittanbietern (wie AAD und Google App directory synchronization, nicht im Szenario gezeigt), und event ID-TOKEN von OpenID Connect, wenn Sie auf das Szenario 1 achten.

Szenario 1 - Graph-API und Client-Anwendung mit OAuth2-Autorisierungscode Grant Flow

  1. Der Benutzer greift auf die Client App zu.
  2. Die Client-App leitet die Anfrage an den OAuth2-Autorisierungsdienst für das Zugriffstoken weiter
  3. Autorisierungsdienst leitet Anfrage an Sign-In STS zur Authentifizierung des Benutzers weiter
  4. Der Benutzer meldet sich mit der Windows Azure Active Organisation ID an
  5. Der Sign-In STS gibt das Authentifizierungstoken an den Autorisierungsdienst aus
  6. Der Autorisierungsdienst gibt den Autorisierungscode an die Client-App aus

https://<client-app-url>?code=AgAAAAAAf_ZCy7KzPg7iR6C3VIKPO2zI4EZaP4C6….

7. Die Client-App sendet den Autorisierungscode an den Autorisierungsserver für das OAuth2-Zugriffstoken

POST https://login.windows.net/common/oauth2/token

grant_type=authorization_code&client_id=<client-app-id>&redirect_uri=<client-app-url>&client_secret=<client-key>&code=AgAAAAAAf_ZCy7KzPg7iR6C3VIKPO2zI4EZaP4C6….

8. Die Client-App erhält ein OAuth2-Zugangs-Token

{

"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1....",

"token_type": "Inhaber",

"expires_in": "28799″,

“expires_on”:”1374051298″,

"multi_resource":true,

"refresh_token": "AgAAAAAAEU1fnhQZ832bVHuQfLSPZfh...",

“scope”:”62e90394-69f5-4237-9190-012177145e10″,

"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJh.....9."

}

9. Die Client-App ruft die Graph-API auf, um Benutzerinformationen abzurufen, und übergibt das OAuth2-Zugangs-Token im HTTP-Autorisierungs-Header.

https://graph.windows.net/me?api-version=2013-04-05

Autorisierung: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng

10. Die Client-App erhält die Benutzerinformationen

{

"odata.metadata": "https://graph.windows.net/myorganization/$metadata#directoryObjects/

Microsoft.WindowsAzure.ActiveDirectory.User/@Element",

"odata.type": "Microsoft.WindowsAzure.ActiveDirectory.User",

"objectType": "Benutzer",

“objectId”:”9e3c71d1-6972-4f48-a117-d808a7abf19c”,

"accountEnabled":true,

"displayName": "Testbenutzer",

...

"userPrincipalName": "[email protected]"

}

Szenario 2 - Vorintegrierter Anwendungszugang mit Google App for Business

1. Der Benutzer greift auf das Bedienfeld Anwendungszugriff zu

https://account.activedirectory.windowsazure.com/applications/default.aspx

2. Der Benutzer wird zum Sign-In STS weitergeleitet

3. Der Benutzer meldet sich mit der Windows Azure Active Organisation ID an

4. Der Nutzer klickt auf Google App for Business access

https://account.activedirectory.windowsazure.com/applications/redirecttoapplication.aspx?Operation=SignIn&applicationId=01303a13-8322-4e06-bee5-80d612907131&ApplicationConstName=googleapps&FederatedAuthentication=true

5. Windows Azure gibt SAML 2.0 SAMLResponse an Google App aus

POST https://www.google.com/a/<google-app-domain>/acs

<samlp:Response ID=”_6935dfb6-11c7-4859-8063-4b7c495ef871″ Version=”2.0″ IssueInstant=”2013-07-28T23:46:34.772Z” Destination=”https://www.google.com/a/solesoul.net/acs” InResponseTo=”id257e68d977b340e89705a873ea626e9d” xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”>

....

<Assertion ID=”_d420e5e1-4d40-4718-b404-215ff0e0b4bb” IssueInstant=”2013-07-28T23:46:34.772Z” Version=”2.0″ xmlns=”urn:oasis:names:tc:SAML:2.0:assertion”>

<Issuer>https://sts.windows.net/<tenant-id>/</Issuer>

<Subject><NameID>[email protected]</NameID>….</Subject>…

<Audience>https://google.com</Audience></AudienceRestriction>….

<AttributeStatement>

<Attribute Name=”https://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”>

<AttributeValue>test</AttributeValue>

</Attribute>

<Attribute Name=”https://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”>

<AttributeValue>user</AttributeValue>

</Attribute><Attribute Name=”https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”>

<AttributeValue>user@<google-app-domain></AttributeValue>

</Attribute>

<Attribute Name=”https://schemas.microsoft.com/identity/claims/tenantid”>

<AttributeValue>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</AttributeValue>

</Attribute>

<Attribute Name=”https://schemas.microsoft.com/identity/claims/objectidentifier”>

<AttributeValue>9e3c71d1-6972-4f48-a117-d808a7abf19c</AttributeValue>

</Attribute>

<Attribute Name=”https://schemas.microsoft.com/identity/claims/identityprovider”>

<AttributeValue>https://sts.windows.net/<tenant-id>/</AttributeValue>

</Attribute>

</AttributeStatement>

<AuthnStatement AuthnInstant=”2013-07-28T23:45:01.000Z” …>

</Assertion>

</samlp:Response>

6. Google App verbraucht das SAML-Token und startet die Landing Page

Szenario 3 - Azure Mobile Service mit Android Mobile App und Facebook

  1. Benutzer klickt auf Mobile App für den Zugriff auf Kontaktinformationen von Azure Mobile Service
  2. Die Mobile App startet den OAuth2 Implicit Grant Fluss mit Facebook
  3. Die Mobile App und anschließend der Azure Mobile Service erhalten das OAuth2-Zugriffstoken

access_token=CAACjMY5EUnIBAMZBadVhspVyKAW...Mu26YnSHvbhJEuwZD&expires=5183999

4. Azure Mobile Service ruft Benutzerinformationen von Facebook ab und übergibt Zugriffstoken

https://graph.facebook.com/me?access_token=CAACjMY5EUnIBAMZBadVhspVyK…Mu26YnSHvbhJEuwZD

{

“id”:”1000000xxxxxxxx”,

"Name": "Test User",

...

“updated_time”:”2013-05-22T20:06:32+0000“

}

5. Mobile App erhält authenticationToken von Azure Mobile Service

{

“user”:{“userId”:”Facebook:1000000xxxxxxxx”},

"authenticationToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpX...-QwWhRjFHBOEqPAcsXoLqjENoY"

}

6. Die App ruft die Liste der Kontaktinformationen durch Übergabe des X-ZUMO-AUTH-Tokens ab

GET https://<tenant-mobile-service-name>.azure-mobile.net/tables/Contact

X-ZUMO-INSTALLATION-ID: 3959a7fd-9af5-4145-b35b-1d5d7e2f5e8d

X-ZUMO-AUTH: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6MH0.....qPAcsXoLqjENoY

7. App fügt neuen Kontakt zur Kontaktliste mit HTTP POST hinzu

POST https://jakeoauthmvc.azure-mobile.net/tables/Contact

X-ZUMO-AUTH: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCI...sfwkqr-QwWhRjFHBOEqPAcsXoLqjENoY

.....

8. App-Updates Telefonnummer des Erstkontakts

PATCH https://jakeoauthmvc.azure-mobile.net/tables/Contact/1

X-ZUMO-AUTH: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCI...sfwkqr-QwWhRjFHBOEqPAcsXoLqjENoY

....

9. App löscht den ersten Kontakt

DELETE https://jakeoauthmvc.azure-mobile.net/tables/Contact/1

X-ZUMO-AUTH: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCI...sfwkqr-QwWhRjFHBOEqPAcsXoLqjENoY

HTTP/1.1 204 Kein Inhalt

Szenario 4 - Office 365-Dienst und ADFS vor Ort

  1. Der Benutzer greift auf den webbasierten Office 365-Dienst zu.
  1. Der Office 365-Dienst leitet die Anfrage an Sign-In STS weiter
  1. Der Benutzer meldet sich mit UPN an
  1. Der Sign-In STS leitet die Anfrage basierend auf dem UPN an den On-Premise ADFS weiter
  1. Der Benutzer meldet sich mit On-Premise AD an
  1. Der On-Premise-ADFS übergibt das Token an den Sign-In-STS
  1. Der Sign-In STS wandelt das Token um und gibt dann ein neues Token an den Office 365-Dienst aus.
  1. Der Office 365-Dienst validiert das neue Token und wendet dann die erforderlichen Zugriffskontrollprüfungen an, bevor er dem Benutzer den Zugriff auf den Dienst gestattet.