Yo sólo pasaba por aquí pero ya que estoy....

Cómo hacer uso del tenant de WAAD de Office 365 junto con ACS

2013-05-16T13:48:00Z

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.

Securizar aplicaciones web usando Windows Azure Active Directory

2013-05-14T10:33:00Z

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.

Hasta ahora hemos visto varios ejemplos de securización de aplicaciones dónde siempre hemos hecho uso de Windows Azure Access Control. En este post hablaremos de Windows Azure Active Directory el cuál puede usarse de forma independiente a ACS o como un proveedor de identidad más de ACS.

Como en los ejemplos anteriores, partiremos de una aplicación ASP.NET MVC 4, en la cuál queremos incluir un mecanismo de seguridad basado en WAAD.

Para ello, lo primero, necesitaremos crear a través del portal de Windows Azure un tenant de WAAD. Tened en cuenta que los tenant van asociados a los usuarios, no a la subscripción, y sólo se permite uno por usuario. Además, a día de hoy no se puede borrar una vez creado…

Comentar que Office 365 usa WAAD, por lo que si ya tenéis una cuenta de Office 365 ya tenéis un tenant de WAAD que podrías usar, tal y como veremos en el siguiente post.

Desde este menú podremos crear nuestro tenant, indicando los datos del mismo.

Una vez creado, podremos crear usuarios, usuarios que son los que usaremos para autenticarnos en la aplicación.

Y si lo preferimos, podemos sincronizar el tenant que acabamos de crear con un Active Directory que tengamos on-premise y así usar los mismos usuarios que tengamos ya creados.

Una vez que tenemos los usuarios, podemos dar de alta las aplicaciones que queremos securizar.

e indicar el identificar único de la aplicación, como la URL dónde está desplegado. Si estamos probando en local la URL será algo como http://localhost:29350/

Una vez hecho estos pasos iremos a la aplicación web y volveremos a hacer uso de la herramienta que nos permite configurar la seguridad basada en WIF.

En este caso, indicaremos que queremos usar Windows Azure Active Directory, indicando el identificador único de la aplicación que hemos puesto anteriormente, así cómo la URL a los metadatos del STS. Esta URL se obtiene desde el portal de Windows Azure, dentro de la aplicación que hemos creado.

Y una vez hecho estos pasos, si ejecutamos la aplicación (F5) veremos cómo se nos redirige a la página de login dónde deberemos introducir las credenciales del un usuario de WAAD o de nuestro dominio si es que lo tuviéramos sincronizado.

Cómo securizar una aplicación que contenga tanto aplicaciones web como servicios WebAPI

2013-05-09T13:02:00Z

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

En los ejemplos anteriores hemos visto cómo securizar una aplicación ASP.NET MVC y una aplicación WebAPI haciendo uso de ACS y tokens JWT.

¿Pero qué pasa si en el mismo proyecto tenemos las dos cosas? Una aplicación web a la cuál un usuario puede acceder a través del navegador y un servicio WebAPI que se usa tanto desde el javascript de la aplicación web, como desde otros clientes como pueden ser una aplicación Windows 8 o Windows Phone.

En este caso, tendremos que hacer los pasos vistos en los dos post anteriores, pero veremos cómo una vez juntos no van a funcionar las llamadas al servicio WebAPI, salvo las propias que podamos hacer desde el javascript de la aplicación.

Cuando hacemos uso de WIF para autenticar la aplicación web, TODAS las llamadas que se realizar deben estar autenticadas. En caso de no estar autenticadas, se nos redirige a la pantalla de login para que podamos introducir las credenciales.

Si las llamadas las intentamos realizar por código, por ejemplo desde una aplicación Windows 8 haciendo uso de httpClient, estas llamadas serán igualmente redirigidas a la pantalla de login, aunque mandemos en las cabeceras el token de seguridad.

Solución? En mi caso lo he solucionado de la siguiente manera:

Lo primero es añadir la posibilidad de llamar a los servicios WebAPI a través de dos rutas diferentes. Una de las rutas será usada por la aplicación web, cuando desde el código JavaScript quiera llamar a estos servicios, mientras la otra ruta será usada para el resto de clientes; Windows 8, Windows Phone…

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

            config.Routes.MapHttpRoute(
                name: "DefaultApiJs",
                routeTemplate: "apijs/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

En el fichero de configuración establezco que la ruta que va a ser usada por las “aplicaciones externas” permita llamadas anónimas.

  <location path="api">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

y por último, en el DelegationHandler haré que sólo se valide el token si la llamada no es autenticada.

if (Thread.CurrentPrincipal.Identity.IsAuthenticated)
            {
                return base.SendAsync(request, cancellationToken);
            }

De esta manera conseguimos:

Si un usuario accede a través del navegador se le pedirán las credenciales para poder entrar en la web. Una vez autenticado, todas las llamadas que se hagan desde el JavaScript ya estarán autenticadas, por lo que no es necesario que el DelegationHandler haga nada.

Cuando hacemos por código desde una aplicación externa, haremos uso de la ruta que permite llamada anónimas y así evitar que se nos mande a la página de login. En este caso, el DelagationHandler sí tendrá que validar el token de seguridad y establecer la identidad en la llamada.

Cómo securizar servicios WebAPI usando ACS y tokens JWT

2013-05-07T15:48:00Z

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

En el primer post de la serie veíamos cómo es posible securizar una aplicación web ASP.NET MVC como ACS y token JWT. En este post haremos un ejemplo similar, pero securizando un servicio ASP.NET WebAPI al cuál queremos llamar desde un cliente de forma segura.

Una vez creada, veremos cómo ésta aplicación tiene unos controladores de ejemplo que podemos usar para el ejemplo que estamos mostrando, ya que lo que nos importante en este caso es cómo securizar el acceso.

Con el proyecto de ejemplo, si ejecutamos la aplicación con F5 podemos acceder a los controladores WebAPI a través del protocolo GET desde el propio navegador y ver los resultados que devuelve. Al no tener seguridad cualquiera puede consultarlos.

Una vez que tenemos la aplicación de ejemplo, como en caso anterior, será necesario crear un namespace de ACS así como una relaying party con las URLs dónde estamos desplegando el servicio WebAPI en local.

Para seguir con el ejempo, el siguiente paso será añadir una referencia a System.IdentityModel, así como instalar a través de Nuget “JSON Web Token Handler For the Microsoft .Net Framework 4.5”, paquete que va a proporcionarnos diferentes clases para el manejo de tokens JWT.

Una vez realizado estos pasos, la principal diferencia con el ejemplo de MVC es que aquí no podremos hacer uso de la herramienta “Identity and Access…” que veíamos en el post anterior y la cuál nos permitía configurar nuestra aplicación para hacer uso de ACS.

En este caso tendremos que desarrollar nuestro propio DelegatingHandler para que poder validar en todas las peticiones que se realicen al servicio WebAPI que el cliente está debidamente autenticado contra el proveedor de identidad y STS que tengamos configurado en nuestro ACS.

A través del Global.asax añadiremos nuestro validador personalizado, el cuál se encarga de asegurarse de que el token se envían en las cabeceras de todas las peticiones, que el token es correcto y es establecer la identidad para que desde los controladores WebAPI pueda acceder a toda la información del usuario autenticado, por ejemplo, los claims.

GlobalConfiguration.Configuration.MessageHandlers.Add(new TokenValidationHandler());

El código de nuestro handler sería el siguiente:

 internal class TokenValidationHandler : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            HttpStatusCode statusCode;
            string token;

            if (!TryRetrieveToken(request, out token))
            {
                statusCode = HttpStatusCode.Unauthorized;
                return Task<HttpResponseMessage>.Factory.StartNew(() => new HttpResponseMessage(statusCode));
            }

            try
            {
                // Use JWTSecurityTokenHandler to validate the JWT token
                JWTSecurityTokenHandler tokenHandler = new JWTSecurityTokenHandler();

                List<string> issuers = new List<string>();
                issuers.AddRange(ConfigurationManager.AppSettings["Issuers"].Split(new[] { ',' }));

                // Set the expected properties of the JWT token in the TokenValidationParameters
                TokenValidationParameters validationParameters = new TokenValidationParameters()
                {
                    AllowedAudience = ConfigurationManager.AppSettings["AllowedAudience"],
                    ValidIssuers = issuers,

                    // Fetch the signing token from the FederationMetadata document of the tenant.
                    SigningToken =
                    new X509SecurityToken(new X509Certificate2(GetSigningCertificate(ConfigurationManager.AppSettings["ida:FederationMetadataLocation"])))
                };

                Thread.CurrentPrincipal = tokenHandler.ValidateToken(token, validationParameters);
                HttpContext.Current.User = Thread.CurrentPrincipal;

                return base.SendAsync(request, cancellationToken);
            }
            catch (SecurityTokenValidationException)
            {
                statusCode = HttpStatusCode.Unauthorized;
            }
            catch (Exception)
            {
                statusCode = HttpStatusCode.InternalServerError;
            }
            return Task<HttpResponseMessage>.Factory.StartNew(() => new HttpResponseMessage(statusCode));
        }

        // This function retrieves ACS token (in format of OAuth 2.0 Bearer Token type) from 
        // the Authorization header in the incoming HTTP request from the ShipperClient.
        private static bool TryRetrieveToken(HttpRequestMessage request, out string token)
        {
            token = null;
            IEnumerable<string> authzHeaders;
            if (!request.Headers.TryGetValues("Authorization", out authzHeaders) || authzHeaders.Count() > 1)
            {
                // Fail if no Authorization header or more than one Authorization headers 
                // are found in the HTTP request 
                return false;
            }

            // Remove the bearer token scheme prefix and return the rest as ACS token 
            var bearerToken = authzHeaders.ElementAt(0);
            token = bearerToken.StartsWith("Bearer ") ? bearerToken.Substring(7) : bearerToken;
            token = bearerToken.StartsWith("Authorization Bearer ") ? bearerToken.Substring(21) : bearerToken;
            return true;
        }

        public static byte[] GetSigningCertificate(string metadataAddress)
        {
            if (metadataAddress == null)
            {
                throw new ArgumentNullException(metadataAddress);
            }

            using (XmlReader metadataReader = XmlReader.Create(metadataAddress))
            {
                MetadataSerializer serializer = new MetadataSerializer()
                {
                    CertificateValidationMode = X509CertificateValidationMode.None
                };

                EntityDescriptor metadata = serializer.ReadMetadata(metadataReader) as EntityDescriptor;

                if (metadata != null)
                {
                    SecurityTokenServiceDescriptor stsd = metadata.RoleDescriptors.OfType<SecurityTokenServiceDescriptor>().First();

                    if (stsd != null)
                    {
                        X509RawDataKeyIdentifierClause clause = stsd.Keys.First().KeyInfo.OfType<X509RawDataKeyIdentifierClause>().First();

                        if (clause != null)
                        {
                            return clause.GetX509RawData();
                        }
                        throw new Exception("The SecurityTokenServiceDescriptor in the metadata does not contain the Signing Certificate in the <X509Certificate> element");
                    }
                    throw new Exception("The Federation Metadata document does not contain a SecurityTokenServiceDescriptor");
                }
                throw new Exception("Invalid Federation Metadata document");
            }
        }

    }

Si una vez realizado estos cambios, volvemos a ejecutar la aplicación y realizamos una llamada desde el navegador, veremos cómo todas las llamadas pasan por nuestro validador personalizado, el cuál rechazará todas las llamadas que no contenga un token de seguridad validado.

El último paso del ejemplo será realizar un cliente C# que sea capaz de llamar al servicio WebAPI pasando un token de seguridad válido para nuestro STS.

En este caso he creado un proyecto de Test, al que he añadid el paquete “Windows Azure Authentication Library”, el cuál simplifica enormemente el trabajo con WIF, ya sea con ACS o con Windows Azure Active Directory.

El siguiente código muestra cómo es posible realizar una llamada al servicio WebAPI.

En el ejemplo se hace uso de la clase AuthenticationContext disponible en WAAL, en la cuál indicamos el namespace de ACS con el que estemos trabajando, así como el nombre de la relaying party para el cuál queremos obtener un token de seguridad.

El método AcquireToken nos mostraré una interfaz de usuario en función del proveedor o proveedores configurados en ACS, para que podamos autenticarnos.

Una vez autenticados, podremos generar un token para poder mandarlo en las cabeceras de autenticación. En este caso, el delegationHandler que hemos desarrollado anteriormente validará correctamente el token y establecerá la identidad en la llamada.

[TestClass]
    public class DemoWebAPITests
    {
        [TestMethod]
        [TestCategory("Integration")]
        public async Task TestWebAPIService()
        {
            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");

        }
    }

Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de WIF

2013-05-02T13:18:00Z

Siguiente con la serie de posts dedicada a la securización de aplicaciones, este post veremos cómo desplegar en Windows Azure Web Sites la aplicación web desarrollada en el post anterior y un par de puntos que tendremos que tener en cuenta para que todo funcione sin problemas.

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 KWT.
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

El primer paso es crear un nuevo Web Site desde el portal de WIndows Azure dónde desplegaremos la aplicación ASP.NET desarrollada en el post anterior y que hace uso de ACS y tokens JWT.

Una vez creado el site, modificaremos en namespace de ACS para que en lugar de hacer uso las URL locales, haga uso de las URL de WIndows Azure dónde desplegaremos la aplicación.

En este caso estamos modificando la misma relaying party que teníamos ya, pero en un escenario real os recomendaría tener dos “relaying party”, una configurada para funcionar en local y otra para funcionar cuando esté desplegada en Windows Azure y hacer uso de las transformaciones que soporta web.config para que cuando ésta se despliega en Windows Azure la configuración sea modificada para tener la configuración adecuada.

El siguiente paso, será utilizar el wizard de publicación que nos proporciona el Sdk de Windows Azure para publicar de manera directamente desde Visual Studio.

Este wizard de forma sencilla nos permite indicar las credenciales de nuestra subscripción Windows Azure, así como indicar el servicio sobre el que se quiere desplegar la aplicación, tal y como se ve en las imágenes siguientes:

Y una vez desplegada, si lo hacemos con los errores remotos activados ( <customErrors mode="Off"></customErrors> ) veremos el siguiente error!!

The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.

Este error se produce por el uso DAPI, método por defecto para proteger las cookies en aplicaciones WIF y el cuál no está disponible en Windows Azure Web Sites.

Cambiarlo es sencillo, ya que la propia herramienta nos permite indicar que queremos usar un método alternativo, chequeando la opción “Enable Web farm ready cookies” en el pestaña de configuración del asistente “Identity and Access…”.

Sino podemos cambiar manualmente estas entradas en el fichero de configuración:

 <securityTokenHandlers>  
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

Barrica Tech Day en Logroño!

2013-05-02T10:04:00Z

El próximo 25 de mayo celebraremos un evento en Logroño dónde todos los que queráis estáis invitados a venir! Aquí os dejo todos los detalles del mismo.

Registro: http://barricatechday.eventbrite.com/

10:00 – 10:50 Desarrollo de aplicaciones web con Silex por Asier Marques (@asiermarques) de Simettric

Silex es un framework ágil y muy profesional para desarrollar aplicaciones web con PHP. Silex reduce el tiempo de desarrollo de aplicaciones pequeñas a horas y el de aplicaciones medianas a días.

Durante la sesión podremos ver:

¿Por qué Silex?
Cómo trabajar con Silex.
Cómo escalar Silex.

10:00 – 10:50 Git por Fernando Perez (@ferpega_) de Plain Concepts

Los repositorios de código se han convertido en una pieza fundamental del desarrollo de software hoy día. Usarlos es esencial para cualquier proyecto, sea del tamaño que sea y esté formado por una sola persona o por varios equipos.

En esta sesión veremos las diferencias entre repositorios de código centralizados y descentralizados y ahondaremos en la terminología y particularidades que han hecho de GIT el repositorio que cuenta con un mayor crecimiento hoy día, pasando después por una introducción a los comandos básicos de GIT y algunas utilidades gráficas que pueden facilitarnos la vida en nuestros inicios con este fantástico gestor de código fuente.

12:00 – 12:50 Montando un escenario de integración continúa por Ibon Landa (@ibonilm) de Plain Concepts

Durante esta sesión se mostrará de forma práctica cómo es posible montar un escenario de integración continua dónde se pueda construir el software cada vez que se realiza alguna modificación y pasar las pruebas de forma automatizada, a la vez que se hace uso de una plataforma de Cloud Computing para desplegarla durante el proceso.

Durante la sesión se empleará Azure WebSites como plataforma de Cloud Computing dónde desplegar las aplicaciones, plataforma que permite trabajar con GitHub, TFS Service, Bitbucket o CodePlex para crear escenarios de integración continua.

13:00 – 13:50 Pruebas funcionales en la web con CasperJS por Vicenç Garcia (@vgaltes) de Plain Concepts

Las pruebas funcionales son un mal necesario cuando estamos desarrollando software. Así como las pruebas unitarias nos ayudan a asegurar que estamos haciendo las cosas correctamente, las pruebas funcionales nos ayudarán a asegurar que estamos haciendo las cosas correctas.

Como toda prueba de nuestro sistema, es necesario que la podamos pasar tantas veces como sea necesario y con el menor coste para nosotros como sea posible, así que automatizarlas se antoja vital.

En esta sesión veremos cuando puede ser interesante hacer este tipo de pruebas y veremos cómo podemos apoyarnos en CasperJS para codificarlas.

Usando ACS y tokens JWT para securizar aplicaciones web

2013-05-01T14:50:14Z

El objetivo de este post y alguno que intentaré ir escribiendo más adelante es intentar explicar en detalle cómo es posible securizar tanto aplicaciones web ASP.NET MVC como servicios WebAPI empleando Windows Azure Access Control y token JWT. Así mismo entraré en escenarios dónde se haga uso del nuevo servicio Windows Azure Active Directory.

En esta serie trataré los siguientes temás:

Cómo securizar aplicaciones web usando ACS y tokens JWT.
Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de ACS.
Cómo securizar servicios WebAPI usando ACS y tokens KWT.
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.

En este primer post trataré el primero de los temas, sobre cómo es posible securizar una aplicación ASP.NET MVC haciendo uso de ACS y token JWT.

El primer paso para este ejemplo será crear un namespace de ACS desde el portal de Windows Azure. Una vez que hemos accedido a nuestra subscripción de Windows Azure tendremos que crear un namespace como se ve en la siguiente imagen:

Una vez que tenemos el namespace podemos acceder a la administración del namespace y realizar la configuración que necesitemos para nuestra aplicación. En este caso, para simplificar el ejemplo, usaremos Windows Live Id como proveedor de identidad, pero como seguramente ya sabréis, es posible configurar múltiples proveedor, como un tenant de Windows Azure Active Directory (WAAD), un ADFS de un dominio on-premise o un tenant de Office 365 como veremos en post posteriores.

Una vez que tenemos en namespace configurado, crearé una aplicación de ejemplo ASP.NET MVC 4 usando la plantilla de aplicación Internet.

Para seguir con el ejemplo es importante asegurarnos de que en nuestro equipo de desarrollo tenemos instalado Windows Identity Foundation así como las herramientas para trabajar con Windows Azure Active Directory; Microsoft ASP.NET Tools for Windows Azure Active Directory – Visual Studio 2012. También antes de instalar las herramientas es necesario instalar ASP.NET and Web Tools 2012.2 Update

Una vez instalado estos componentes, si seleccionamos el proyecto web que acabamos de crear, veremos una nueva opción de menú “Identiy and Access…” que nos ayudará a securizar las aplicaciones web de una forma rápida y “sencilla”.

Este asistente nos permite indicar el tipo de seguridad que queremos aplicar a la aplicación web, ya sea haciendo uso de ACS, de WAAD o de un STS local que podamos haber desarrollado nosotros. En el ejemplo que estamos desarrollando en este post elegiremos la última de las tres opciones que se nos presentan.

Una vez selecciona la opción de ACS tendremos que indicar el nombre de nuestro namespace, así como la key de administración que obtenemos del portal de Windows Azure. Indicando el nombre del namespace así como la key de administración el propio wizard podrá conocer los proveedores de identidad que tenemos configurados así como crear una “relaying party” para la aplicación que estamos desarrollando.

En este caso, como estamos desarrollando en nuestro entorno local, indicaremos las URL dónde nuestra aplicación ASP.NET MVC se hostea en nuestro servidor local. En mi caso, http://localhost:28732/

Esta operación, entre otras cosas, lo que hace es crear una “relaying party” en namespace de ACS, en la cuál podremos configurar el tipo de token que queremos emplear, que como hemos comentado anteriormente, serán JSON Web Token (JWT), un formato compacto que está cogiendo bastante popularidad gracias al hecho de que se puede usar desde diferentes lenguajes y plataformas…así como que es usando por empresas como Amazon (Fusion Middleware), Google (App Engine Security Module) o SalesForce en alguno de sus productos.

Así mismo, JWT es el formato que usa Windows Azure Active Directory y que también está soportado en modo Beta en Access Control, escenario que estamos viendo en este post.

Otro paso importante que no debemos olvidar es crear las reglas de ACS que queremos aplicar, para que a nuestra aplicación web puedan llegar los claims que nos interesen desde el proveedor de identidad.

En este caso estamos usando Windows Live ID, por lo que veremos que al generar las reglas únicamente se nos creará una nueva regla que hará que llegue a la aplicación en nameidentifier del usuario autenticado. El número y tipo de claims depende de cada proveedor de identidad.

Una vez realizados estos pasos si intentamos ejecutar la aplicación (F5) veremos cómo una vez nos autenticamos en la aplicación con unas credenciales válidas de Windows Live ID nos encontramos con el siguiente error, que viene por el uso de JWT como formato de token.

ID4014: A SecurityTokenHandler is not registered to read security token ('BinarySecurityToken', 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd').

Para poder solucionar este problema, necesitaremos crear nuestro propio SecurityTokenHandler que soporte token de tipo JWT.

El primero paso será añadir una referencia a System.IdentityModel, así como instalar a través de Nuget “JSON Web Token Handler For the Microsoft .Net Framework 4.5”, paquete que va a proporcionarnos diferentes clases para el manejo de tokens JWT.

Una vez que lo tengamos instalado, tenemos que crear una nueva clases que herede de JWTSecurityTokenHandler.

  public class CustomJwtSecurityTokenHandler : JWTSecurityTokenHandler
    {
        public override ClaimsPrincipal ValidateToken(JWTSecurityToken jwt, TokenValidationParameters validationParameters)
        {
            if ((validationParameters.ValidIssuer == null) &&
                (validationParameters.ValidIssuers == null || !validationParameters.ValidIssuers.Any()))
            {
                validationParameters.ValidIssuers = new List<string> { ((ConfigurationBasedIssuerNameRegistry)Configuration.IssuerNameRegistry)
                    .ConfiguredTrustedIssuers.First().Value };
            }

            if (validationParameters.SigningToken == null)
            {
                validationParameters.SigningToken = new X509SecurityToken(new X509Certificate2(
                    GetSigningCertificate(ConfigurationManager.AppSettings["ida:FederationMetadataLocation"])));

            }
            return base.ValidateToken(jwt, validationParameters);
        }

        protected override string NameIdentifierClaimType(JWTSecurityToken jwt)
        {
            return ClaimTypes.GivenName;
        }

        public static byte[] GetSigningCertificate(string metadataAddress)
        {
            if (metadataAddress == null)
            {
                throw new ArgumentNullException(metadataAddress);
            }

            using (XmlReader metadataReader = XmlReader.Create(metadataAddress))
            {
                MetadataSerializer serializer = new MetadataSerializer()
                {
                    CertificateValidationMode = X509CertificateValidationMode.None
                };

                EntityDescriptor metadata = serializer.ReadMetadata(metadataReader) as EntityDescriptor;

                if (metadata != null)
                {
                    SecurityTokenServiceDescriptor stsd = metadata.RoleDescriptors.OfType<SecurityTokenServiceDescriptor>().First();

                    if (stsd != null)
                    {
                        X509RawDataKeyIdentifierClause clause = stsd.Keys.First().KeyInfo.OfType<X509RawDataKeyIdentifierClause>().First();

                        if (clause != null)
                        {
                            return clause.GetX509RawData();
                        }
                        throw new Exception("The SecurityTokenServiceDescriptor in the metadata does not contain the Signing Certificate in the <X509Certificate> element");
                    }
                    throw new Exception("The Federation Metadata document does not contain a SecurityTokenServiceDescriptor");
                }
                throw new Exception("Invalid Federation Metadata document");
            }
        }
    }

Una vez que tenemos la clase creada, a través del fichero de configuración, tendremos que hacer las modificaciones necesarias para que haga uso de la nueva clase que acabamos de crear: (sección securitytokenHandlers)

y ahora sí, si ejecutamos la aplicación con F5 e introducimos unas credenciales válidas, veremos llegamos a ver la aplicación ASP.NET MVC!!

WebCast de Windows Azure

2013-04-02T07:55:33Z

Por segundo año consecutivo, tendrá lugar el Megathon Windows 8, un evento que se celebra de manera simultánea en varias ciudades, donde tendrás la oportunidad de crear apps para Windows 8 y Windows Phone, aprender y conocer a otros programadores y ganar fabulosos premios.

Previo a este evento se están celebrando una serie de WebCast para permitir a las personas que quieran participar ponerse las pilas en diversas tecnologías.

Entre las sesiones que se impartirán habrá cuatro dedicadas a Windows Azure, en dos de las cuáles tendré el placer de participar. Aquí os dejo la información.

2 de Abril de 2013 de 19'00 a 19'40 - Azure Mobile Services: Autenticación de usuarios con servicios de internet

Veremos cómo incorporar servicios de autenticación de internet en nuestras aplicaciones. Nuestros usuarios podrán registrarse con sus identidades de twitter, Facebook, google o Microsoft Id.

4 de Abril de 2013 de 19'00 a 19'40 - Azure Mobile Services: Almacenando datos de apps en la nube

La nube nos permite almacenar de forma centralizada la información para compartirla entre usuarios o entre dispositivos, haremos un ejercicio para entender la forma más sencilla de almacenar y recuperar datos de apps en Windows azure.

9 de Abril de 2013 de 19'00 a 19'40 - Azure Mobile Services: Personalizando el servidor

Windows Azure Mobile Services nos permite añadir nuestro código para extender la funcionalidad por defecto y adaptarlo a nuestras necesidades, por ejemplo realizando validaciones sobre los datos que van a almacenarse

11 de Abril de 2013 de 19'00 a 19'40 - Azure Mobile Services: Notificaciones push a dispositivos

Las notificaciones nos permiten tener un mayor nivel de interacción con los usuarios de nuestras apps, pero los diferentes dispositivos dificultan el desarrollo de los módulos de . notificaciones. Windows Azure Mobile Services ofrece un servicio unificado de notificaciones para diferentes dispositivos (Win8, WinPhone, Android e IOS)

También habrá sesiones de Windows 8, Windows Phone 8 o TFS, las cuáles podéis ver aquí.

Mejoras en el plugin de Eclipse

2013-03-02T10:14:11Z

Si habéis desplegado alguna vez una aplicación Java en Windows Azure os habréis dado cuenta que el empaquetado que genera Eclipse es bastante grande, ya que dentro del mismo además de los ficheros de la aplicación se debe incluir la versión del jdk y el servidor de aplicación correspondiente.

El hecho de que el empaquetado fuese grande implica que los procesos de despliegue sean bastante más tediosos de lo podrían ser, ya que además del proceso de subida del fichero dentro del proceso de despliegue Windows Azure hace varias copias internas que claro está, a más tamaño, son más lentas.

Pues nada, con la última actualización del plugin de Eclipse ya tenemos una alternativa, que no es otra que desplegar el jsdk y el servidor de aplicación desde el Windows Azure Storage. Así que si estáis trabajando con Java os recomiendo que uséis esta opción.

Plugin de Eclipse para TFS

2013-01-31T13:23:00Z

En un post anterior veíamos como era posible instalar y usar el plugin de Windows Azure para Eclipse, para poder desplegar aplicaciones Java en Windows Azure de una forma relativamente sencilla.

En este post os comentaré otro plugin que nos permite trabajar con Team Foundation Server de forma sencilla desde Eclipse, para cualquier tipo de aplicación, y teniendo una experiencia prácticamente igual a la que se puede tener desde Visual Studio.

Este plugin permite trabajar tanto con un TFS propio, como la versión en la nube que podéis llegar a usar de forma gratuita desde http://tfs.visualstudio.com/ ; gestor de fuentes, sistema de integración continua, workitems, informes etc… todo en cuestión de minutos y hasta 5 usuarios de forma gratuita!!

La instalación se realizar desde la opción de instalación de nuevo software, indicando el repositorio dónde éste se encuentra.

Una vez indicado el repositorio podemos ver el plugin y proceder con la instalación.

Una vez instalado podemos añadir a la perspectiva el Team Explorer, que como veréis es prácticamente idéntico al que os podéis encontrar en Visual Studio.

Desde esta ventana podréis indicar la dirección de vuestro TFS, os podéis conectar al proyecto que queráis y empezar a trabajar con los servicios que necesitéis…subir vuestro código fuente, crear vuestras builds de integración continua, añadir vuestras historias de usuario, tareas etc…

Windows Azure Command Line Tools

2013-01-30T13:02:00Z

Una de las principales herramientas de interoperabilidad que tenemos son las herramientas de líneas de comandos de windows Azure, las cuáles están disponibles para Windows, Linux y MAC.

Esta herramienta la podemos descargar desde el portal de Windows Azure ( http://www.windowsazure.com/en-us/manage/downloads/ ) o desde el repositorio de GitHub https://github.com/windowsazure/azure-sdk-tools-xplat

Esta herramienta nos va a permitir realizar diferentes labores administrativas sobre los servicios de Windows Azure; máquinas virtuales, websites, mobile services etc…todo desde línea de comandos y desde cualquier sistema operativo.

Esta herramienta está hecha en node.js y lo podemos instalar desde el package manager.

npm install azure-cli –g

Eso sí, importante revisar que tenemos la versión adecuada de node.js. Por ejemplo, la versión que se instala desde el software manager de Ubuntu 12.10 instala una versión que no cumple con los requisitos mínimos, por lo que es recomendable acudir a la máquina principal de node.js ( http://nodejs.org/ ) e instalar la última release disponible, en este momento, la v.0.8.17.

Una vez instalada la herramienta, podemos ver los diferentes commandos disponibles poniendo el nombre del nombre, “azure”.

La sintaxis sigue el siguiente formato: (los comandos cogerlos a modo de referencia ya que se van añadiendo nuevas funcionalidades de forma periódica)

Una vez instalada, si queremos empezar a trabajar con nuestra subscripción, será establecer las credencial de la cuenta o cuentas de Windows Azure que queremos administrar.

Para ello podemos invocar al comando azure account download.

Abriendo esta URL desde el navegador e introduciendo las credenciales de nuestra subscripción Windows Azure nos podemos descargar un fichero que contiene toda la información de seguridad necesaria para poder administrar la subscripción.

Una vez descargado el comando azure account import <file> nos permitirá importar las credenciales y empezar a administrar la subscripción.

Una vez tenemos las credenciales, ya podemos usar la herramienta para ver nuestros servicios, crear nuevos servicios, modificar su estado etc….

Por ejemplo, podemos administrar nuestros web sites. Con el parámetro –h podemos ver la ayuda y los comandos disponibles.

Si queremos crear un nuevo web site, podremos hacer azure site create. Si no indicamos más parámetros, la herramienta nos pedirá la información que falta, como el datacenter o el nombre del servicio.

Si listamos los sites veremos el nuevo site.

y si te interesa saber más sobre interoperabilidad, te animo a que vengas al Cloud Tour http://www.plainconcepts.com/cloudtour/

Windows Azure Store

2013-01-24T12:31:00Z

Windows Azure dispone de un montón de funcionalidades “de serie”, pero en más de una ocasión utilizamos herramientas hechas por terceros ya sea para obtener más servicios que los que ofrece la plataforma o para disponer de nuevo funcionalidad no existente en la plataforma.

El disponer de estas herramientas no es algo nuevo, pero lo que sí es nuevo es que ahora las tenemos integradas dentro del portal de administración. Podemos disponer de un catálogo de aplicaciones, comprarlas, usarlas etc…todo desde el portal.

A través del portal de administración podemos acceder a la opción “ADD-ONS”, la cuál nos dará acceso a un catálogo de aplicaciones hechas por terceros a las cuáles podemos acceder, ya sea de forma gratuita o de pago.

Podemos ver herramientas de monitorización con AppDynamics o NewRelic, servicios para trabajar con MySQL, MongoDB, SendGrid….como se puede ver en las siguientes pantallas.

Comentar por último, comentar que este servicio todavía no está disponible para todas las subscripciones y es posible que te encuentren con un mensaje con este…

Windows Azure y Java: Afinidad de sesión

2013-01-22T08:58:00Z

Como veíamos en un post anterior es posible trabajar de forma sencilla con Windows Azure y Java empleando el plugin de Eclipse. Vimos cómo crear una aplicación Java y cómo desplegarla junto con las versiones del JDK y Tomcat que necesita la aplicación web.

Una caso con el que habitualmente te suelen encontrar desplegando aplicaciones Java, al menos con las que yo me he encontrado, es que se necesita afinidad de sesión…que si despliego la aplicación en múltiples servidores quiero que las diferentes peticiones que se hagan desde la misma máquina se hagan siempre usando el mismo servidor.

Abro el navegador, empiezo a navegar por la aplicación y todas las peticiones de la sesión se tienen que hacer siempre usando el mismo servidor….y ¿esto lo permite por defecto Windows Azure? NO, pero hay soluciones.

Cuando hay más de una instancia de un rol desplegado en Cloud Services Windows Azure se encarga de realizar de forma automática el balanceo de carga, pero no hace un balanceo por afinidad de sesión ni nos permite establecer la configuración de cómo queremos que se comporte, es una cosa transparente para nosotros.

Para este tipo de escenarios el plugin de Eclipse dispone de una opción que nos permite indicar si queremos disponer de afinidad de sesión (sticky sessions) en la aplicación que vamos a desplegar, “tan sencillo como marcar un check”.

¿Qué hace?

Pues disponer de afinidad de sesión usando el módulo ARR (Application Request Routing) de Internet Information Server, el cuál permite disponer de afinidad por sesión.

Cuando marcamos esta opción, el plugin modificar los ficheros de arranque del proyecto de Windows Azure para que se instale el módulo de ARR en las instancias que desplegamos. El módulo de ARR se puede instalar por línea de comandos de forma sencilla, utilizando el Microsoft Web Platform Installer.

Cuando no tenemos esta opción activada, cuando realizamos una petición a la aplicación el balanceador de Windows Azure decide el servidor que tiene que atender la petición y se la envía directamente al Tomcat que tenemos desplegado en la máquina, en el puerto que tengamos configurado.

Cuando activamos la opción, el módulo de ARR de IIS se pone por medio. El balanceador manda las peticiones al servidor que él considera, pero estas peticiones le llega al ARR y éste la redirecciona de nuevo al servidor Tomcat que toque teniendo en cuenta la afinidad de sesión.

Esto se consigue poniendo el IIS y el Tomcan el puerto diferentes, por ejemplo el IIS en el puerto 80 y el Tomcat en el 8080. Windows Azure manda todas las peticiones al puerto 80, el módulo de ARR decide qué servidor tiene que tratar la petición y lo redirecciona por el puerto 8080 para que le llegue al Tomcat…eso sí, el ARR en su lógica de decisión mantiene la afinidad de sesión.

Claro está, esto no es una cosa propia de aplicaciones Java, pero en este plugin de Eclipse está bastante bien solucionado, mejor incluso que Visual Studio dónde no tenemos esta opción.

Eso sí, si queremos hacer aplicaciones escalables, es mejor evitar siempre la afinidad de sesión, no es una buena práctica.

PD: y si te interesa saber más sobre interoperabilidad, te animo a que vengas al Cloud Tour http://www.plainconcepts.com/cloudtour/

Windows Azure, Java y Eclipse

2013-01-15T11:16:00Z

Como ya he comentado en más de una ocasión Windows Azure es una plataforma abierta para trabajar con diferentes tecnologías y sistemas operativos, disponiendo de diferentes herramientas y SDKs para cada ocasión.

En este post quiero enseñaros una de las opciones que hay de interoperabilidad, que no es otra que el plugin de Eclipse para trabajar con Java y poder desplegar este tipo de aplicaciones en un Cloud Service, en la parte de plataforma como servicio de Windows Azure.

Para poder instalar este plugin en Eclipse es necesario tener instalado el Sdk de Windows Azure (1.8 o superior), el JDK 1.6 o superior y la versión de Eclipse para Java EE Developers.

Una vez que se tienen instalados estos prerequisitos la instalación del plugin resulta bastante sencillo, desde la opción de instalación de nuevo software, tal y como se ve en la primera imagen.

Para poder encontrar el plugin a instalar es necesario indicar el respositorio de software; http://dl.msopentech.com/eclipse

Una vez realizado este sencillos pasos ya podemos crear nuestras aplicaciones Java o abrir alguna de las que ya tengamos y empezar a desplegarlas en Windows Azure! Que como veréis, es un proceso bastante sencillo.

Para los que conozcáis Visual Studio y hayáis trabajo con él y Windows Azure, veréis que la experiencia de usuario es prácticamente igual.

Para esta demo lo primero que haremos es crear una proyecto web, un dynamic web project, dónde tendremos un JSP, nuestro “Hello World” en Java.

y creamos también un JSP para esta demo.

Con los pasos que hemos realizado hasta el momento tendríamos una aplicación Java normal y corriente, pero ahora hay que hacer los pasos necesarios para empaquetar esta aplicación en un formato que Windows Azure pueda entender.

Independientemente del lenguaje de programación en el que se trabaje, para poder desplegar una aplicación en un Cloud Services, es necesario empaquetar la aplicación en un formato que éste pueda entender.

El plugin de Eclipse, al igual que hace Visual Studio, nos permite de forma visual realizar todo este proceso…empaquetar la aplicación e indicar la configuración de despliegue; número de instancias, puertos, protocolos etc…Todo aquello que necesitemos.

Empaquetar la aplicación Java en el formato que necesita Windows Azure es bastante sencillo, empleando el plugin que hemos instalando anteriormente, el cuál veremos que nos ha añadido una barra con diferentes opciones y alguna que otra opción en los menús contextuales.

Por ejemplo, seleccionado el proyecto Java, desde el menú contextual tendremos la opción de empaquetar el proyecto para ser desplegado en Windows Azure, acción que creará un nuevo proyecto especial, propio de Windows Azure, el cuál es el encargado de empaquetar la solución y establecer la configuración que queramos.

La acción empaquetar también nos pedirá la versión del JSDK que queremos que se despliegue junto con mi aplicación, así como qué servidor queremos usar, en el ejemplo Tomcat. Esto es así, porque las máquinas de Windows Azure por defecto no tienen estos dos componentes y por tanto, es necesario que estos se incluyan e instalen junto con nuestra aplicación.

Como he comentado, esta acción generará un proyecto de Windows Azure con un contenido similar a este. En en este proyecto dónde se configurar el WAR que queremos desplegar, el JDK, el Servidor etc…lo que hace el plugin de Eclipse es que no tengamos que hacer nada o casi nada a mano, todo de forma visual desde asistentes y menús de propiedades.

Si seleccionamos las propiedades del rol podremos ver la configuración del mismo; ficheros que se deben incluir en el empaquetado, puertos, protocolos….

Por ejemplo, en esta pantalla podéis ver que los ficheros que incluirán…el JSDK, el servidor, el WAR de la aplicación y un bat que se encarga de la instalación del JSDK y servidor Tomcat.

Otra cosa que podemos llegar a configurar en el acceso remoto, cosa que considero importante siempre configurar, para que podamos conectarnos por RDP a las máquinas que desplegamos en Windows Azure. Esta configuración la podemos establecer desde las propiedades del proyecto de Windows Azure.

Una vez que tenemos esto, podemos usar la barra que nos ha instalado el plugin para primero, probar la aplicación en nuestro entorno local, y luego desplegar la aplicación en Windows Azure.

Desde el propio Eclipse podemos lanzar la aplicación y usar el entorno de emulación que tiene el SDK de Windows Azure para poder probar la aplicación en nuestro entorno local como si éste estuviera desplegado en Windows Azure.

Una vez que ya lo tenemos funcional en el entorno local, tendremos que desplegar la aplicación, ya sea de forma manual o directamente desde Eclipse.

Si queremos hacer un despliegue manual, podremos usar la opción de crear el empaquetado. Esta acción empaquetará los ficheros que hemos indicado con la configuración que hayamos establecido y nos dará dos ficheros; el fichero de definición del servicio y el fichero de configuración del servicio, los dos ficheros que necesito para tener la aplicación funcionando en Windows Azure.

Una vez los tengo generado, tendré que ir a la página de administración de mi subscripción Windows Azure ( http://windows.azure.com/), crear un Cloud Service y usar estos dos ficheros oara crear un despliegue.

y por último, otra opción que tenemos disponible es la opción de configurar en Eclipse las credenciales de la subscripción, desde las propiedades del proyecto.

Si configuro las credenciales, desde el menú contextual podré desplegar directamente la solución en la subscripción que tenga configurada, indicando en ese proceso el Cloud Service dónde desea hacer el despliegue.

Y con esto es todo, como veis, con la el plugin de Eclipse el despliegue de aplicaciones Java resulta bastante sencillo…

Eso sí…

¿Qué pasa si uso Eclipse en Linux o en MAC? ¿Puedo usar este plugin? NO, veremos alternativas…

¿Qué pasa si no uso Eclipse ni Visual Studio? ¿Puedo desplegar otro tipo de aplicaciones (PHP, Node…) en Cloud Services? SI, lo veremos…

¿Qué se despliegue con la aplicación el JDK y el Tomcat no hará que el tamaño del empaquetado sea muy grande? SI, pero también hay soluciones que veremos…

VM Depot: Catálogo open source de máquinas virtuales

2013-01-12T13:00:00Z

VM Depot es una catálogo open source de máquinas virtuales preconfiguradas creado por la comunidad que pueden ser fácilmente desplegadas en Windows Azure. Estas máquinas vienen preconfiguradas con software, aplicaciones, herramientas de desarrollo etc…

Cualquier persona puede ver el catálogo de máquinas existentes y desplegar una máquina virtual en cuestión de minutos en su propia subscripción de Windows Azure, una maravilla!!

y claro está, lo mismo que puedes usar máquinas existentes, puedes crear tus propias imágenes contribuyendo al catálogo.

Este servicio ha sido creado por “Microsoft Open Technologies”, una subsidiaria de Microsoft, y podéis acceder al mismo a través de http://vmdepot.msopentech.com

Ahora mismo ya hay diversas máquinas virtuales de algunos partners como Alt Linux, Basho, Bitnami o Hupstream.

Cualquier usuario puede pertenecer a la comunidad y hacer sus propios aportes. El proceso resulta bastante sencillo, desde el menú de publicar se indica todo lo necesario para poder hacer tus contribuciones:

y desplegar una existente, es tan fácil como generar el script de despliegue, que te la línea de comandos que tienes que lanzar para desplegar la imagen en tu subscripción.

y si quieres saber más sobre el servicio de máquinas virtuales, cómo trabajar con ellas, cómo administrarlas etc…pues igual te interesa acudir al Cloud Tour http://www.plainconcepts.com/cloudtour/

Cloud Tour

2013-01-08T14:41:00Z

Después de las giras de SQL Server, HTML y Visual Studio, le ha tocado el turno a la nube, con una gira que organizamos desde Plain Concepts por cinco ciudades.

Las plataformas de Cloud Computing pueden llegar a ofrecer grandes beneficios a las aplicaciones desplegadas en ellas; ahorro de costes, escalabilidad, disponibilidad...

Durante las diferentes sesiones de este evento veremos cómo trabajar con Windows Azure como plataforma de Cloud Computing, haciendo especial especial hincapié en las diferentes opciones de interoperabilidad que existen y cómo es posible trabajar con lenguajes de programación como Java, Node.js o PHP e incluso desde diferentes sistemas operativos, Linux y MAC.

Agenda:

09:30 Introducción a la plataforma
10:30 IaaS - Linux, Máquinas y Redes Virtuales
11:30 Café
11:45 PaaS, trabajando con Java y Eclipse
12:30 PHP y Azure Web Sites
13:30 Comida
14:30 Almacenamiento en la nube – SQL, NoSQL
15:30 Big Data y Hadoop
16:30 Desarrollo de backends para el desarrollo de aplicaciones móviles

Fechas y ciudades:

30 de enero – Sevilla
31 de enero – Madrid
7 de febrero – Barcelona
12 de febrero – Bilbao
28 de febrero – Santiago

La agenda completa y registro lo podéis encontrar en http://www.plainconcepts.com/cloudtour/

Herramientas de monitorización: Foglight

2012-12-19T12:00:00Z

Hace no mucho comentaba algunas herramientas interesantes para monitorizar aplicaciones desplegadas en Windows Azure.

Hoy os comento otra aplicación que también me ha parecido bastante interesante, peor que todavía no está en versión no release; Foglight

En http://foglight-on-demand.com/content/en/index.html podéis encontrar información completa sobre la aplicación y cómo acceder a una versión de pruebas de 30 días. De momento, al no estar en versión release, no tiene una política de precios, pero la herramienta no pinta nada mal, habrá que estar atento.

Una vez que tengáis la cuenta creada podréis configurar de forma muy rápida la monitorización indicando la subscripción que queréis monitorizar y el certificado de administración de la cuenta. Una vez que hayáis incluido estos datos el sistema descubre las aplicaciones desplegadas para que podáis indicar cuáles de ellas queréis monitorizar.

Una vez configurado, se puede ver información muy interesante de diagnóstico, configurar alertas etc…

Windows Server 2012 Roadshow en Bilbao

2012-12-04T08:59:00Z

El próximo 14 de diciembre pasará por Bilbao el Roadshow de Windows Server 2012, dónde tendré la suerte de acompañar a Samuel Lopez hablando con Windows Server 2012 en Windows Azure, y la creación de nube híbridas para aprovechar lo mejor de los dos mundos.

Registro:

https://ws2012rocks.msregistration.com/abstract.aspx?id=7d701162-706c-474e-a801-3ad70ab0658f&Eventid=268

Agenda:

9:00 - 9:15 Registro
9:15 - 9:30 bievenida (Samuel López)
9:30 - 10:30 Windows Server 2012 Novedades (Samuel López)
10:30 - 11:45 Hyper-V 3.0 (Samuel lópez)
11:45 - 12:00 Descanso
12:00 - 13:00 Windows Azure y nubes hibridas (Ibon Landa)

Espero veros allí!

Tip: Herramientas de monitorización de Windows Azure

2012-11-22T17:41:00Z

Cómo monitorizar Azure? Qué herramienta es la máquina adecuada? y permite PaaS, IaaS, SQL Database etc…son las típicas preguntas que surgen cuando desplegamos en Windows Azure.

El nuevo portal ofrece más información que el anterior, pero generalmente resulta insuficiente para muchas aplicaciones, lo que hace que se tengan que valorar otras herramientas.

Aunque System Center permite realizar muchas de estas tareas, es una herramienta que un muchos casos excede enormemente las necesidades que tenemos en cuanto a monitorización, siendo una herramienta demasiada completa y cara para lo que suelen necesitar muchas empresas que están desplegando en Windows Azure. Ojalá ofrezcan este servicio en la nube!!

Dos las herramienta que más me ha gustado bastante, no son las únicas, son AppDynamics y NewRelic.

Ambas herramientas se basan en la instalación de un agente dentro de la máquina, que recoge toda la información de monitorización y diagnóstico de la misma y la centraliza para que ésta pueda ser accesible a través de una consola web de administración.

En la página oficial de Windows Azure podéis encontrar información detallada sobre cómo es posible hacer uso de NewRelic, cómo conseguir una cuenta, el coste y cómo poder desplegar su agente para disponer de toda la información de monitorización y diagnóstico.

Del mismo modo podéis encontrar información sobre AppDynamics en su web bastante detallada.

Añadir un Cloud Service a una red virtual

2012-11-21T08:21:00Z

Como todos seguro que ya sabéis desde junio una de las grandes novedades de la plataforma son la posibilidad de desplegar máquinas virtuales dentro de Windows Azure. Para los que no lo conozcáis, resumiendo y simplificando un poco podemos decir que es un Hyper-V en la nube, dónde podemos desplegar cualquier tipo de sistema operativo, Microsoft o Linux.

Así mismo, otra de las grandes novedades es la posibilidad de crear redes virtuales entre las máquinas que tenemos desplegadas en la plataforma o incluso entre servidores que tengamos en la nube con servidores que tengamos en un entorno local, posibilitando escenarios de nube híbrida con un potencia descomunal.

Generalmente me estoy encontrando que muchos asocian las redes virtuales sólo con la posibilidad de crear máquinas virtuales, como si sólo se pudiese crear este tipo de red entre máquinas virtuales…pues no! las redes virtuales están tanto para IaaS como para PaaS, es decir, tanto para máquinas virtuales como para cloud services.

Es más que posible que esta confusión viene del hecho de que Visual Studio, ni ningún otro IDE, permite configurar de forma visual la red virtual en la que queremos incluir un determinado despliegue de Cloud Services. Si queremos que una aplicación desplegada en un Cloud Services se una a una red virtual, tendremos que modificar el XML de configuración del servicio de forma manual.

<NetworkConfiguration>
  <VirtualNetworkSite name="NetworkName" />
  <AddressAssignments>
    <InstanceAddress roleName="Web">
      <Subnets>
        <Subnet name="SubNetName" />
      </Subnets>
    </InstanceAddress>
  </AddressAssignments>
</NetworkConfiguration>