Windows Azure: Acceso y federación de identidades en la nube

Según el artículo en línea de Microsoft, Windows Azure ofrece una gestión de identidades y accesos segura y preparada para la empresa en la nube.

• Directorio activo de Windows Azure
• Integración con su directorio activo local
• Ofrezca control de acceso para sus aplicaciones
• Crear conexiones sociales en toda la empresa
• Proporcione un inicio de sesión único en todas sus aplicaciones en la nube
• Mejoras en el acceso a las aplicaciones preintegradas (Vista previa)
  • Servicios móviles de Windows Azure
  • Autenticación activa de Windows Azure (vista previa)

Recorramos los siguientes cuatro escenarios de acceso y federación de identidades en la nube que demuestran cómo la tecnología Windows Azure Identity potencia las mejores prácticas de soluciones de integración en la nube con OAuth2 (Código de autorización y flujos de concesión implícitos en los escenarios, Credenciales de cliente con Windows Azure Access and Control Service, JWT con SharePoint Online nuevo App Model y Graph API - no mostrado en el escenario), SAML, WS-Federation (Pasivo en el escenario y Activo), Graph API, Mobile y Web App, REST, ADFS, Office365, Social Identity Providers, App API de terceros (como AAD y Google App directory synchronization, no mostrado en el escenario), y event ID-TOKEN de OpenID Connect si se presta atención al escenario 1.

Escenario 1 - API Gráfica y Aplicación Cliente con OAuth2 Código de Autorización Flujo de Concesión

1. El usuario accede a la aplicación cliente.
2. La aplicación cliente redirige la solicitud al servicio de autorización OAuth2 para obtener el token de acceso.
3. El servicio de autorización redirige la solicitud al STS de inicio de sesión para autenticar al usuario.
4. El usuario inicia sesión con Windows Azure Active organization ID
5. El STS de inicio de sesión emite el token de autenticación al servicio de autorización
6. El servicio de autorización emite un código de autorización a la aplicación cliente

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

7. La aplicación cliente envía el código de autorización al servidor de autorización para obtener el token de acceso 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. La aplicación cliente recibe el token de acceso OAuth2

{

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

"token_type": "Portador",

"expires_in": "28799″,

“expires_on”:”1374051298″,

"multi_resource":true,

"refresh_token": "AgAAAAAAEU1fnhQZ832bVHuQfLSPZfh...",

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

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

}

9. La aplicación cliente invoca la llamada Graph API para recuperar la información del usuario, pasando el token de acceso OAuth2 en la cabecera HTTP Authorization.

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

Autorización: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng

10. La aplicación cliente recibe la información del usuario

{

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

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

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

"objectType": "Usuario",

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

"accountEnabled":true,

"displayName": "usuario de prueba",

...

"userPrincipalName": "[email protected]"

}

Escenario 2 - Acceso a aplicaciones preintegrado con Google App for Business

1. El usuario accede al panel de Acceso a Aplicaciones

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

2. El usuario es redirigido a Sign-In STS

3. El usuario inicia sesión con Windows Azure Active organization ID

4. El usuario hace clic en Acceso a 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 emite SAML 2.0 SAMLResponse a 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 consume el token SAML y lanza la página de destino

Escenario 3 - Azure Mobile Service con Android Mobile App y Facebook

1. El usuario hace clic en la aplicación móvil para acceder a la información de contacto de Azure Mobile Service
2. La aplicación móvil inicia el flujo OAuth2 Implicit Grant con Facebook
3. La aplicación móvil y Azure Mobile Service reciben el token de acceso OAuth2.

access_token=CAACjMY5EUnIBAMZBadVhspVyKAW...Mu26YnSHvbhJEuwZD&expires=5183999

4. Azure Mobile Service recupera la información de usuario de Facebook, pasando el token de acceso

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

{

“id”:”1000000xxxxxxxx”,

"name": "Usuario de prueba",

...

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

}

5. La aplicación móvil obtiene authenticationToken de Azure Mobile Service

{

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

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

}

6. La aplicación recupera la lista de información de contacto pasando el token 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. La aplicación añade un nuevo contacto a la Lista de Contactos con HTTP POST

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

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

.....

8. Número de teléfono del primer contacto

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

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

....

9. La aplicación borra el primer contacto

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

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

HTTP/1.1 204 Sin contenido

Escenario 4 - Servicio Office 365 y ADFS local

1. El usuario accede al servicio Office 365 basado en web.

2. El servicio Office 365 redirige la solicitud a Sign-In STS

3. El usuario inicia sesión con UPN

4. El STS de inicio de sesión redirige la solicitud al ADFS local basándose en el UPN.

5. El usuario inicia sesión con AD local

6. El ADFS local presenta el token al STS de inicio de sesión

7. El STS de inicio de sesión transforma el token y, a continuación, emite un nuevo token para el servicio de Office 365.

8. El servicio de Office 365 valida el nuevo token y, a continuación, aplica las comprobaciones de control de acceso necesarias antes de permitir el acceso del usuario al servicio.