Windows Azure : Accès à l'identité dans le nuage et fédération

D'après l'article en ligne de Microsoft, Windows Azure permet une gestion des identités et des accès sécurisée et adaptée à l'entreprise pour le nuage.

• Windows Azure Active Directory
• Intégration avec votre répertoire actif sur site
• Offrir un contrôle d'accès à vos applications
• Créer des liens sociaux au sein de l'entreprise
• Fournir une authentification unique pour l'ensemble de vos applications en nuage
• Amélioration de l'accès aux applications pré-intégrées (Preview)
  • Services mobiles Windows Azure
  • Windows Azure Active Authentication (Preview)

Passons en revue les quatre scénarios suivants d'accès et de fédération d'identité dans le nuage qui démontrent comment la technologie Windows Azure Identity permet de mettre en place des solutions d'intégration dans le nuage avec OAuth2 (Code d'autorisation et flux de subvention implicite dans les scénarios, Client Credentials avec Windows Azure Access and Control Service, JWT avec SharePoint Online new App Model et Graph API - non montré dans le scénario), SAML, WS-Federation (passif dans le scénario et actif), Graph API, Mobile and Web App, REST, ADFS, Office365, Social Identity Providers, third party App API (tel que AAD et Google App directory synchronization, non montré dans le scénario), et event ID-TOKEN de OpenID Connect si vous prêtez attention au scénario 1.

Scénario 1 - API graphique et application client avec code d'autorisation OAuth2 Flux d'octroi

1. L'utilisateur accède à l'application client.
2. L'application client redirige la demande vers le service d'autorisation OAuth2 pour obtenir un jeton d'accès.
3. Le service d'autorisation redirige la demande vers le STS d'entrée pour authentifier l'utilisateur.
4. L'utilisateur se connecte avec l'identifiant de l'organisation active Windows Azure.
5. Le STS d'ouverture de session délivre le jeton d'authentification au service d'autorisation.
6. Le service d'autorisation délivre un code d'autorisation à l'application cliente.

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

7. L'application cliente soumet le code d'autorisation au serveur d'autorisation pour obtenir le jeton d'accès OAuth2.

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. L'application cliente reçoit un jeton d'accès OAuth2.

{

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

"token_type" : "Bearer",

"expires_in" : "28799″,

“expires_on”:”1374051298″,

"multi_resource":true,

"refresh_token" : "AgAAAAEU1fnhQZ832bVHuQfLSPZfh...",

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

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

}

9. L'application cliente lance un appel à l'API Graph pour récupérer les informations relatives à l'utilisateur, en transmettant le jeton d'accès OAuth2 dans l'en-tête d'autorisation HTTP.

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

Autorisation : Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng

10. L'application client reçoit les informations de l'utilisateur

{

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

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

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

"objectType" : "User",

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

"accountEnabled":true,

"displayName" : "test user",

...

"userPrincipalName" : "[email protected]"

}

Scénario 2 - Accès aux applications pré-intégrées avec Google App for Business

1. L'utilisateur accède au panneau d'accès aux applications

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

2. L'utilisateur est redirigé vers la STS de connexion.

3. L'utilisateur se connecte avec Windows Azure Active organization ID

4. L'utilisateur clique sur l'accès à Google App for Business

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

5. Windows Azure envoie une réponse SAML 2.0 SAMLResponse à Google App

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 consomme le jeton SAML et lance la page de renvoi.

Scénario 3 - Azure Mobile Service avec Android Mobile App et Facebook

1. L'utilisateur clique sur l'application mobile pour accéder aux informations sur les contacts à partir d'Azure Mobile Service.
2. L'application mobile démarre le flux OAuth2 Implicit Grant avec Facebook.
3. L'application mobile et Azure Mobile Service reçoivent le jeton d'accès OAuth2.

access_token=CAACjMY5EUnIBAMZBadVhspVyKAW...Mu26YnSHvbhJEuwZD&expires=5183999

4. Azure Mobile Service récupère les informations de l'utilisateur à partir de Facebook, en passant le jeton d'accès.

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

{

“id”:”1000000xxxxxxxx”,

"nom" : "Utilisateur test",

...

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

}

5. L'application mobile reçoit l'authenticationToken d'Azure Mobile Service.

{

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

"authenticationToken" : "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpX...-QwWhRjFBOEqPAcsXoLqjENoY"

}

6. L'application récupère la liste des informations de contact en passant le jeton X-ZUMO-AUTH.

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. L'application ajoute un nouveau contact à la liste des contacts avec HTTP POST

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

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

.....

8. Mises à jour de l'application Numéro de téléphone du premier contact

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

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

....

9. L'application supprime le premier contact

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

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

HTTP/1.1 204 Pas de contenu

Scénario 4 - Service Office 365 et ADFS sur site

1. L'utilisateur accède au service Office 365 basé sur le web.

2. Le service Office 365 redirige la demande vers Sign-In STS

3. L'utilisateur se connecte avec son UPN

4. Le STS de connexion redirige la demande vers l'ADFS sur site sur la base de l'UPN.

5. L'utilisateur se connecte avec AD sur site

6. L'ADFS sur site présente le jeton au STS de connexion.

7. Le STS de connexion transforme le jeton et émet ensuite un nouveau jeton pour le service Office 365.

8. Le service Office 365 valide le nouveau jeton et applique ensuite les contrôles d'accès nécessaires avant d'autoriser l'utilisateur à accéder au service.