Una característica interesante cuando desplegamos nuestras aplicaciones en Windows Azure Web Sites es la posibilidad de tener un streaming en tiempo real de las trazas de la aplicación, cosa que resulta muy útil, sobre todo en tiempo de desarrollo.

Esta funcionalidad está disponible para todos los frameworks y lenguajes que están soportados en la plataforma, en el caso de aplicaciones .NET, se integra perfectamente con System.Diagnostics.

Por ejemplo, si partimos de una aplicación de ejemplo de ASP.NET MVC, podemos añadir las siguientes trazas de información, error o advertencia en cada uno de los controladores que tenemos:

public ActionResult Index()
{
    Trace.TraceInformation("Index action selected!");

    ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
    return View();
}

public ActionResult About()
{
    Trace.TraceError("About action selected!");

    ViewBag.Message = "Your app description page.";
    return View();
}

public ActionResult Contact()
{
    Trace.TraceWarning("Contact action selected!");

    ViewBag.Message = "Your contact page.";
    return View();
}

Después de desplegar la aplicación en la plataforma, podemos hacer uso de las herramientas de líneas de comandos, disponibles en todas las plataformas, para conectarnos al site y ver las trazas que se van generando.

El comando es: azure site log tail <site>

La herramienta permite tanto ver el log en tiempo real, como descargarse los logs.

Aquí tenemos un ejemplo de las trazas generadas.

Y aquí un ejemplo dónde filtro por las trazas que tienen la palabra “Index”.

Claro está, además de poder ver o descargar el log desde la línea de comandos, también podemos conectarnos por FTP a nuestro site y ver los logs generados. Por defecto la plataforma divide el log en ficheros máximos de 128k. Así mismo permite por defecto hasta 1 Mb de log para la aplicación. Los logs permanecen en el sistema hasta un máximo de 12 horas.

Desde la configuración del site, en el portal de Windows Azure, podremos ver y modificar la configuración del site.

Si no tenemos activada el log de la aplicación y nos conectamos con la herramienta de línea de comandos, ésta activará automáticamente el log.

Por último, comentar también que modificar la configuración de las trazas de la aplicación no implica que se recicle el pool y que no tanto se reinicie nuestro site. La configuración de diagnóstico se guarda en un fichero settings.json al que podemos acceder por FTP y verlo en el directorio diagnostics.

Log se guarda por defecto 12 horas

Si se conectas con la herramienta de línea de comandos para ver el streaming, te activa automáticamente el log.

Por defecto los ficheros se dividen en partes de 128K y el log siempre queda por debajo de 1 MB. Se pueden sobreescribir estos valores.

Cambiar la configuración de diagnóstico no recicla el pool y ni reinicia tu aplicación.

• Cómo securizar aplicaciones web usando ACS y tokens JWT.
• Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de WIF.
• Cómo securizar servicios WebAPI usando ACS y tokens JWT.
• Cómo securizar una aplicación MVC que contenga tanto aplicaciones web como servicios WebAPI.
• Cómo securizar aplicaciones web usando Windows Azure Active Directory ( WAAD ).
• Cómo hacer uso del tenant de WAAD de Office 365 para securizar aplicaciones web con ACS.
• Securizar aplicaciones Windows 8 con ACS y WAAD
• Securizar aplicaciones Windows Phone 8 con ACS

Siguiendo con la serie de post sobre gestión de identidad y seguridad basada en claims, después de ver cómo es posible securizar aplicaciones Windows 8, en esta entrada toca hablar de Windows Phone 8.

Para este ejemplo partimos de post anterior, dónde veíamos cómo usar WebAutenticationBroker para securizar aplicaciones Windows 8, y los cambios que debíamos hacer en nuestro servicio WebAPI para generar el token que autenticación.

En Windows Phone 8 NO tenemos disponible la librería Windows Autentication Library (AAL), ni tampoco el WebAutenticationBroker, pero aún así, veremos cómo el código a realizar es bastante sencillo.

Después de crear una aplicación de ejemplo de Windows Phone 8 en Visual Studio, crearemos una nueva página llamada SignIn.xaml dónde meteremos la lógica de autenticación. En la página principal de nuestra aplicación podemos añadir la lógica necesaria para que si el usuario no está autenticado, se le lleve a esta página.

La página de SingIn lo único que va a tener es un control WebBrowser, que será el encargado de mostrar la página de autenticación del proveedor o proveedores de identidad que tengamos configurados en Windows Azure Access Control.

En la página sólo tendremos que código, para que en el webrowser se vea la ventana de login del proveedor de identidad.

Fijaros en que la URL que mostramos es exactamente la misma que usábamos en el ejemplo de Windows 8 con WebAuthenticationBroker. Al igual que el ejemplo anterior, el namespace del ACS es “estoyenlanube”, mientras que el servicio WebAPI lo tengo desplegado en https://estoyenlanube.azurewebsites.net. Lo tengo desplegamos en un servidor real porque ACS no es capaz de redirigir a direcciones localhost.

public SignIn()
{
    InitializeComponent();

    signInBrowser.IsScriptEnabled = true;

}

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    string authURL = string.Format(
        "https://estoyenlanube.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=https://estoyenlanube.azurewebsites.net/&wreply=https://estoyenlanube.azurewebsites.net/api/federation");

    //navigate to it
    signInBrowser.Navigate(new Uri(authURL));
}

Con este código mostramos la ventana de login, pero una vez autenticado tenemos que ser capaces de coger el token de autenticación para poder usarlo en las llamadas a nuestro servicio WebAPI. Para ello usaremos el evento Naviagating para llamar cuando el navegador va a la URL que le hemos que tiene que redirigir una vez autenticado. El token lo obtenemos de la misma manera que el ejemplo de Windows 8.

private void Navigating(object sender, NavigatingEventArgs e)
{
    string returnURL = e.Uri.ToString();
    if (returnURL.StartsWith("https://estoyenlanube.azurewebsites.net/api/federation/end"))
    {
        e.Cancel = true;
        signInBrowser.Visibility = System.Windows.Visibility.Collapsed;
        var token = returnURL.Substring(returnURL.IndexOf("token=", StringComparison.Ordinal) + 6);
        DoGet(token);
    }
}

async Task DoGet(string token)
{
    HttpClient httpClient = new HttpClient();
    httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Authorization", "Bearer " + token);

    var response = await httpClient.GetStringAsync(https://estoyenlanube.azurewebsites.net/api/values);
}

Trabajando con virtualización una de las funcionalidades habituales que tenemos es la posibilidad de generar snapshots de nuestras máquinas virtuales, los cuáles nos permiten volver cuando queremos a tener la máquina en el estado en el que estaba cuando lo creamos.

Trabajando con Windows Azure no tenemos de forma directa esta funcionalidad, pero sí tenemos la posibilidad de generar snapshots de los ficheros VHDs sobre el que se monta la máquinas virtual, por lo que al menos tenemos una posible alternativa.

La primera opción que podemos usar es utilizar una herramienta que disponga ya de esta funcionalidad, como Cloud Storage Studio. Esta herramienta nos permite conectarnos a un storage de Windows Azure y ver los VHDs sobre los que montan las máquinas virtuales. Cerebrata también dispone de Cmdlets de powershell que ofrecen la misma funcionalidad.

Una vez seleccionado el blob podemos generar snaphots, ver los snapshots existentes, promocionar uno etc…

Otra opción, si no tenemos una herramienta que nos ofrezca la funcionalidad, es usar nosotros directamente el API de Windows Azure para hacernos nuestra propia aplicación que haga los snapshots.

A modo de ejemplo, aquí os dejo un código que se conecta a un almacenamiento de Windows Azure, genera un snapshot y luego lo restaura.

private CloudBlobClient blobClient;
private const string storageName = "<storagename>";
private const string privateKey = "<privatekey>";

[TestMethod]
public void TestBlobSnapshot()
{
    string connectionString = String.Format("DefaultEndpointsProtocol=https;AccountName={0};AccountKey={1}", storageName,privateKey);
    CloudStorageAccount account = CloudStorageAccount.Parse(connectionString);
    blobClient = account.CreateCloudBlobClient();

    CloudBlobContainer testcontainer = new CloudBlobContainer("vhds",blobClient);

    // Upload a blob to the storage service, populate under the current container
    var blobRef = testcontainer.GetBlobReference("sourcetobackup.vhd");

    // Create a snapshot for the blob
    CloudBlob snapshotRef1 = blobRef.CreateSnapshot();

    // restore from snapshop
    var blobTargetRef = testcontainer.GetBlobReference("newserver.vhd");
    blobTargetRef.DeleteIfExists(new BlobRequestOptions()
    {
        // need to specify this option in order to delete blob with snapshots
        DeleteSnapshotsOption = DeleteSnapshotsOption.IncludeSnapshots
    });

    blobTargetRef.CopyFromBlob(snapshotRef1);

}

• Cómo securizar aplicaciones web usando ACS y tokens JWT.
• Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de WIF.
• Cómo securizar servicios WebAPI usando ACS y tokens JWT.
• Cómo securizar una aplicación MVC que contenga tanto aplicaciones web como servicios WebAPI.
• Cómo securizar aplicaciones web usando Windows Azure Active Directory ( WAAD ).
• Cómo hacer uso del tenant de WAAD de Office 365 para securizar aplicaciones web con ACS.
• Securizar aplicaciones Windows 8 con ACS y WAAD

Después de unos cuántos post sobre gestión de identidad y seguridad basada en claims, en esta nueva entrada toca hablar sobre cómo securizar aplicaciones Windows 8, escenario que es algo distinto a los que hemos visto hasta ahora.

En muchos casos, cuando realizamos aplicaciones Windows 8 éstas necesitan hacer uso de servicios de backend, WebAPI por ejemplo, los cuáles pueden estar securizados empleado Windows Azure Active Directory (WAAD) o Windows Azure Access Control, tal y como hemos visto en los post anteriores. Cualquiera de las dos opciones pueden ser válidas para el caso dónde nos encontramos.

En cualquiera de los dos escenarios, la aplicación Windows 8 tendrá que pedir al usuario que se autentique contra el proveedor de identidad configurado para que una vez autenticado la aplicación pueda hacer llamadas a los servicios de backend.

En el post sobre cómo securizar un servicio WebAPI veíamos cómo incluir la seguridad en el servicio y cómo poder hacer un cliente C# que llame a este servicio, pidiendo al usuario las credenciales de autenticación. En ese ejemplo hacíamos uso de Windows Azure Authentication Library para simplicar la seguridad. El código era este:

var authContext = new AuthenticationContext("https://estoyenlanube.accesscontrol.windows.net");
AssertionCredential credential = authContext.AcquireToken("http://localhost:29350/");
var token = credential.CreateAuthorizationHeader();

HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Authorization", token);

var response = await httpClient.GetStringAsync("http://localhost:29350/api/values");

Si intentamos hacer lo mismo en una aplicación Windows 8, veremos cómo también está disponible la librería Windows Azure Authentication Library, pero con una gran diferencia, que ésta sólo funciona si el servicio WebAPI está securizado usando Windows Azure Active Directory, si usamos ACS, este código NO funcionará!

Entonces, si usamos Windows 8 y WAAD el código será prácticamente igual, salvo que el método AcquireToken nos pedirá un ClientID que podemos encontrar dentro del portal de Windows Azure.

y entonces….Qué pasa si usamos ACS para la securización? Pues que el tema se complica un poco; Tendremos que hacer uso del WebAuthenticationBroker y hacer alguna pequeña modificación en nuestro servicio WebAPI.

A modo de resumen, el proceso de autenticación que implementaremos será el siguiente:

• La aplicación Windows 8 usará WebAuthenticationBroker, pidiendo a ACS que autentique el usuario.
• El usuario tiene que introducir las credenciales para el proveedor de identidad configurado.
• Una vez que el ACS autentica al usuario, éste le debe redirigir a un controlador del servicio WebAPI.
• El servicio WebAPI generará un token de autenticación, que devolverá a a la aplicación Windows 8.
• La aplicación Windows 8 podrá usar este token para hacer las llamadas al servicio WebAPI.

Ahora el código…

En la aplicación Windows 8 el código sería similar al siguiente:

WebAuthenticationResult webAuthenticationResult = await WebAuthenticationBroker.AuthenticateAsync(
                WebAuthenticationOptions.None,
                new Uri("https://estoyenlanube.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=https://estoyenlanube.azurewebsites.net/&wreply=https://estoyenlanube.azurewebsites.net/api/federation"),
                new Uri("https://estoyenlanube.azurewebsites.net/api/federation/end"));

            if (webAuthenticationResult.ResponseStatus == WebAuthenticationStatus.Success)
            {
               

En este ejemplo, el namespace del ACS es “estoyenlanube”, mientras que el servicio WebAPI lo tengo desplegado en https://estoyenlanube.azurewebsites.net. Lo tengo desplegamos en un servidor real porque ACS no es capaz de redirigir a direcciones localhost.

https://estoyenlanube.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=https://estoyenlanube.azurewebsites.net/&wreply=https://estoyenlanube.azurewebsites.net/api/federation

Con esta URL le estamos pidiendo al WebAuhenticationBroker que autentique usando el namespace estoyenlanube y el relaying party https://estoyenlanube.azurewebsites.net, Así mismo, le decimos que una vez autentique al usuario redirija la petición a un controlar del servicio WebAPI, el cuál generará el token.

El servicio WebAPI recibirá la petición y generará el token para que el cliente Windows 8 lo obtenga:

public class FederationController : ApiController
    {
        [HttpPost]
        public HttpResponseMessage Post()
        {
            var response = this.Request.CreateResponse(HttpStatusCode.Redirect);
            response.Headers.Add("Location", "/api/federation/end?token=" + ExtractBootstrapToken());
            return response;
        }

        protected virtual string ExtractBootstrapToken()
        {
            var bootstrapContext = ClaimsPrincipal.Current.Identities.First().BootstrapContext as BootstrapContext;
            JWTSecurityToken jwt = bootstrapContext.SecurityToken as JWTSecurityToken;
            return jwt.RawData;
        }
    }

En el fichero de configuración del servicio WebAPI también es necesario cambiar la configuración para que el controlador pueda generar el token:

<identityConfiguration saveBootstrapContext="true">

Finalmente, el cliente Windows 8, si la autenticación es correcta, podrá obtener el valor del parámetro token y usarlo para realizar las llamadas correspondientes al servidor:

var token = webAuthenticationResult.ResponseData.Substring(webAuthenticationResult.ResponseData.IndexOf(“token=”, StringComparison.Ordinal) + 6);

        HttpClient httpClient = new HttpClient();
        httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(“application/json”));
        httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Authorization”, “Bearer ” + token);

        var response = await httpClient.GetStringAsync(“http://localhost:29350/api/values”);

Y ya tenemos todo el proceso

• Cómo securizar aplicaciones web usando ACS y tokens JWT.
• Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de WIF.
• Cómo securizar servicios WebAPI usando ACS y tokens JWT.
• Cómo securizar una aplicación MVC que contenga tanto aplicaciones web como servicios WebAPI.
• Cómo securizar aplicaciones web usando Windows Azure Active Directory ( WAAD ).
• Cómo hacer uso del tenant de WAAD de Office 365 para securizar aplicaciones web con ACS.

Como ya comentaba en el post anterior, Office 365 hace uso de Windows Azure Active Directory para la autenticación, por lo que si posees ya una cuenta de Office 365 ya dispones de un tenant de WAAD para securizar tus aplicaciones.

Si por ejemplo estás autenticado en tu subscripción de Office 365 y vas a http://activedirectory.windowsazure.com podrás ver la información y configuración de tu tenant de WAAD, pero…¿Se puede ver dentro del portal de Windows Azure como veíamos en el post anterior?

Sí, se puede ver dentro del portal de Windows Azure, de dos maneras:

• Creando una subscripción de Windows Azure asociada al administrador de la subscripción de Windows Azure.
• Llamando a centro de soporte para que asocien una subscripción que ya tenga con el usuario administrador de Office 365.

Una vez hecho uno de estos pasos, si estas autenticado en Office 365 con el usuario administrador y vamos al portal de Windows Azure, podremos ver el tenant de WAAD tal y como veíamos en el post anterior.

Sea como sea, en este post vamos a ver cómo podemos usar el tenant de WAAD de Office 365 como un proveedor de identidad de ACS, para lo cuál no necesitamos que el tenant se vea en el portal de Windows Azure.

¿Qué conseguimos con esto?

Si configuramos este proveedor de identidad, podríamos securizar una aplicación web o WebAPI, tal y como ya hemos visto,desplegarlas en Windows Azure y usar los usuarios de Office 365 para autenticarse en todas las aplicaciones,con Single Sign On entre ellas claro.

Si además nos encontramos en un escenario real corporativo, seguramente tendremos el Office 365 sincronizado con nuestro dominio corporativo, por lo que es una manera de usar nuestras credenciales corporativas para logearnos en cualquier aplicación, ya esté en Office 365 o desplegada directamente en Windows Azure.

Desde el portal de Windows Azure, desde el namespace de ACS que hemos estado usando en el resto de ejemplo, añadiremos un nuevo proveedor de identidad de tipo “WS-Federation”.

E indicaremos la URL dónde están los metadatos:

https://accounts.accesscontrol.windows.net/nombredeltenant.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml

Así mismo, podremos configurar las diferentes aplicaciones para que usen los proveedores de identidad que queramos. Hasta ahora habíamos usado siempre Windows Live ID.

Por último, tenemos que configurar el tenant de Office 365 para que permite conexiones del ACS para la autenticación.

Para poder hacer esta configuración no tenemos interfaz de usuario y necesitamos hacer uso las “Windows Azure Active Directory Module for Windows Powershell” para poder lanzar estos comandos y realizar la configuración:

connect-msolservice
import-module msonlineextended –force
$replyUrl = New-MsolServicePrincipalAddresses -Address "https://[yournamespace].accesscontrol.windows.net/"
New-MsolServicePrincipal -ServicePrincipalNames @("https://[yournamespace].accesscontrol.windows.net/")  -DisplayName "[displayName]" -Addresses $replyUrl

Y con estos pasos, ya podremos usar las credenciales que estuviéramos usando en Office 365 para autenticarnos.