No es la primera vez que les hablo de Mobile Services, y de seguro no será la última.

Hace apenas unas semanas les contaba con entusiasmo que utilizando Mobile Services podemos crear un backend para Apps de iOS, Android, Windows Phone 8 y Windows 8.

No contentos con eso ahora cuentas además con SDK de Mobile Services para Windows Phone 7.5 y soporte para Phonegap y en esencia para cualquier sitio web que quiera consumir los servicios que has creado.

Versiones actuales de IE8+, Chrome, Safari, Firefox y Phonegap 2.3.0+ ofrecen la mis estructura de consulta y storage que los otros SDK existentes.

Por si fuera poco, Mobile Services te permite autenticar las solicitudes por cualquiera de los siguientes identity providers

	Microsoft Account
	Google
	Facebook
	Twitter

Si necesitas hacer request por Ajax bien se esperando JSON/JSONP o XML desde dominios diferentes,  Mobile Services te permite trabajar con CORS (Cross Origin Resource Sharing) por lo que puedes crear una ‘White list’ de dominios a los cuales les autorizas el acceso a tus API’s expuestas públicamente.

Próximamente estaré publicando algunos videos introductorios al desarrollo con Mobile Services y estoy seguro que les será de mucha ayuda.

Related Posts

Cómo crear Apps para Windows Phone, Windows 8, IOS y Android con Visual Studio y Windows Azure

Kinect es uno de esos inventos que muchos daban por sentado que sucederían en 50 años, pero Microsoft se encargó de traerlos desde el futuro hasta nuestro tiempo, que sin Kinect luciría algo pre histórico.

Kinect vio la Luz como un dispositivo adicional para Xbox 360, pero rápidamente se popularizo a tal nivel que comenzó  a ser utilizado en muchos proyectos de investigación relacionados con medicina y aprendizaje.

Originalmente existió una API no oficial de Kinect la cual requería conectar el Kinect del Xbox 360 al PC por medio de unos adaptadores. Microsoft tardó un poco en publicar un SDK Oficial pero no solo lanzó un SDK oficial que te permite usar el dispositivo para tus negocios sino que creo una versión especial Kinect optimizada par usar en PCs y con características adicionales capaces de suplir las necesidades de un usuario de PC, diferentes de las de un gamer.

Kinect For Windows es un dispositivo que no solo hace lo mismo que hace Kinect For Xbox 360 sino que adicionalmente posee otras características, tales como:

Soporte para modo de distancias cortas

Por defecto Kinect funciona tal como lo hace en el Xbox 360

Pero Kinect For Windows tiene un modo adicional, llamado modo cercano que permite trabajar a distancias menores:

Reconocimiento de gestos de la mano

A cortas distancias es posible reconocer con más detalle otro tipo de gestos por ejemplo los realizados con la mano para hacer una tarea específica

Posición Sentado

Kinect For Windows puede reconocer cuando una persona esta sentada, bien sea en modo de cortas distancias o normal.

Reconocimiento facial, para detectar gestos o emociones

En modo de cortas distancias Kinect permite realizar reconocimiento facial.

Puede filtrar una voz en particular

Kinect puede filtrar una voz en particular en medio de un conjunto de voces, o bien puede enfocarse en solo escuchar el esqueleto que esta siendo rastreado.:

También es posible usar los sensores para escuchar únicamente sonidos que vengan de una dirección establecida

Puede diferenciar personas que están en actitud de interactuar

Si en el mismo lugar hay varias personas pero solo una o dos o cuatro están realmente interactuando con la aplicación, Kinect puede identificarlos por su actitud corporal y con base en esos datos decidir por ignorar a las demás personas.

Kinect es para ustedes

Cómo lo ven? Kinect For Windows es un dispositivo maravilloso y todos ustedes pueden aprenderlo a explotar para crear aplicaciones increíbles.

Manos a la obra!

Recursos para desarrolladores Kinect!

Kinect SDK & ToolKit

Ejemplos y código fuente de Kinect For Windows

Related Posts

No related posts.

Queremos conocer a estudiantes de pregrado y postgrado, en carreras como Ingeniería de Sistemas, Ingeniería Electrónica o similares.

Trae tu hoja de vida (en inglés y en el estilo de Estados Unidos. Guíate con éste modelo que adjuntamos) http://sdrv.ms/XCQnWs

Pregunta en tu Facultad en dónde será la reunión:

- Lunes 4 de Marzo, 11:00 AM: Bogotá, Escuela Colombiana de Ingeniería Julio Garavito
- Lunes 4 de Marzo, 4:00 PM: Bogotá, Auditorio Microsoft, Cra. 7 No. 71-21 Torre B Piso 15
- Martes 5 de Marzo, 11:00 AM: Bogotá, Universidad de los Andes
- Martes 5 de Marzo, 4:00 PM: Bogotá, Pontificia Universidad Javeriana
- Miércoles 6 de Marzo, 11:00 AM: Medellín, Universidad de Medellín
- Miércoles 6 de Marzo, 5:00 PM: Medellín, Universidad de Antioquia
- Jueves 7 de Marzo, 10:00 AM: Medellín, Universidad Nacional de Colombia
- Jueves 7 de Marzo, 3:00 PM: Medellín, Universidad EAFIT
- Viernes 8 de Marzo, 11:00 AM: Cali, Pontificia Universidad Javeriana
- Viernes 8 de Marzo, 4:00 PM: Cali, Universidad Autónoma de Occidente
- Lunes 11 de Marzo, 8:00 AM: Cali, Universidad del Valle
- Lunes 11 de Marzo, 11:00 AM: Cali, Universidad ICESI
- Lunes 11 de Marzo, 4:30 PM: Cali, Universidad San Buenaventura

También puedes aplicar en línea www.microsoft.com/university

Cómo aplicar para posiciones abiertas:

- Para pasantías, ve a www.microsoft.com/university/softwareintern
- Para posiciones de tiempo complete, ve a www.microsoft.com/university/software
- Al lado izquierdo seleccionar “Software Development Engineer” o “Software Development Engineer in Test”.
- Al lado derecho selecciona el botón azul “Apply Now”

Información importante:

- Información sobre la aplicación, Beneficios de Microsoft, incluyendo relocalización completa, patrocinio de la visa de trabajo en USA y otros está disponible enwww.microsoft.com/university
- Los reclutadores de Microsoft revisan las hojas de vida teniendo en cuenta lo siguiente: 1) Registro Académico, 2) Experiencia de Trabajo Relevante, 3) Liderazgo
- Ten en cuenta que estamos buscando candidatos para Desarrollo de Software, en pasantías y tiempo complete. NOTA: Los candidatos de tiempo complete deben graduarse a más tardar en Junio de 2013. Los candidatos con fecha de graduación posterior a Junio de 2013 serán considerados para pasantías

Related Posts

No related posts.

Espero sus comentarios y no duden en compartir la información.

Si desean unirse al programa BizSpark en Colombia deben escribir a isvcol@microsoft.com

Related Posts

No related posts.

(by @JuanKRuiz )

El mercado de Apps es un mercado de oportunidades, es la democratización de la industria del software, y no es el futuro, una promesa, es una realidad del presente.

Cuando creamos un producto, queremos que este sea exitoso,  nos encontramos con un dilema acerca de las plataformas que queremos soportar versus el costo de producción que esto puede implicar.

Esto es un problema, debido a la forma en que cada plataforma construye sus aplicaciones a veces es inevitable terminar creando tres veces la misma aplicación.

Existen alternativas para solucionar este inconveniente, una de ellas es Phonegap la cual nos permiten crear fácilmente aplicaciones con javascript, css y HTML. Es una alternativa importante y conveniente en muchos escenarios, pero no en todos.

Cuando nuestra aplicación requiere un trabajo más elaborado a nivel de UI la aproximación de Phonegap nos empieza a quedar corta. Cada plataforma tiene características y funcionalidades muy puntuales que con un núcleo común y una interfaz gráfica unificada no logramos cubrir.

Otro aspecto a tener en cuenta es el tema de la segregación de responsabilidades, el despliegue de nuevas versiones y la escalabilidad de los servicios que consume nuestra aplicación, un backend creado de manera tradicional funciona, sin lugar a dudas, pero esta lejos de ser la mejor opción pues no es muy escalable y adicionalmente siempre tendrás que hacer desarrollo desde los diferentes clientes (las Apps) para consumir los servicios provistos por el backend.

Aquí es donde aparece la magia.

Mobile Services, backend en la nube

Lo primero que debemos comenzar a pensar es que en el mundo de la movilidad nuestra aplicación puede y debe utilizar servicios en la nube, es la forma más sencilla de tener un core de negocio único y escalable expuesto a través de interfaces desacopladas como lo son los servicios expuestos por REST, o cualquier otra forma similar de web services,

Si, la nube es una solución para buena parte del trabajo de backend, pero  aún seguimos desarrollando varios clientes para consumir dicho backend.

Aquí es donde la magia entra en juego y esa magia tiene nombre propio Windows Azure Mobile Services, una funcionalidad de Windows Azure que nos permite olvidarnos de la complejidad de la base de datos y de las características puntuales de cada plataforma de desarrollo para enfocarnos en nuestros datos y nada más.

Con Mobile Services puedes crear un backend en cuestión de minutos y permitir que este se extienda o modifique dinámicamente de acuerdo a como manipules tus objetos en la aplicación cliente, toda la funcionalidad esta expuesta haciendo uso de REST pero tu no debes programarlo, ni tampoco debes preocuparte por la conexión a la base de datos ni por construir las tablas.

Por si fuera poco (ya que de por si nos hace más de la mitad del trabajo). Mobile Services ya tiene un SDK para iOS (beta) , Android (beta) , Windows 8 y Windows Phone, qué quiere decir esto?

Quiere decir que ya tienes componentes hechos para consumirlo y que se programa prácticamente igual en cualquiera de las plataformas sin necesidad de repensar tú código, resultado: un solo backend, múltiples plataformas y en un abrir y cerrar de ojos.

C# en cualquier plataforma

Para crear la aplicación cliente requieres definir entidades, librerías, helpers y un sinfín de objetos necesarios para que el software funcione. En cada plataforma debes implementarlos siguiendo la sintaxis y gramática de cada lenguaje, accediendo a clases especificas de cada framework. Un trabajo interesante e incluso apasionante pero que definitivamente requiere de una inversión de tiempo considerable.

Que bueno sería tener la opción de escribir en el mismo lenguaje para las tres plataformas, y porque no poder acceder a varias de las librerías que el CLR nos ofrece.

Esto era una utopía, desarrollar para sistemas iOS, por ejemplo, implica no hacer uso de lenguajes interpretados,  que requieran algún tipo de middleware o runtime para que el sistema permita su ejecución, eso descarta inmediatamente lenguajes como Flash y tristemente lenguajes que se ejecuten sobre un JVM o sobre un CLR como el de .NET.

La industria esta llena de genios, algunos de ellos hacen historia. Miguel de Icaza un desarrollador Mexicano famoso por la creación del proyecto Gnome, el proyecto de Mono y un sinfín de herramientas más se dio cuenta del poder que el CLR y C# pueden dar a los desarrolladores de Apps para dispositivos móviles y ante la restricción de las plataformas decidió modificar el compilador de Mono para que no generara código intermedio (IL) sino que generara código nativo de una vez, el resultado dos productos que desde ya se posicionan como una opción poderosa para desarrollar Apps:

Xamarin.iOS (Monotouch)

Xamarin.Android (Monodroid)

Lo mejor de todo es que existe una versión gratuita que incluye como editor Mono Develop y a partir de la versión Bussiness son 100% compatibles y utilizables desde Visual Studio 2012.

Manos a la Obra

Estoy seguro que si tenias ideas acerca de como crear Apps multiplataforma con este artículo ya has visto la luz, Microsoft promueve y apoya 100% los sistemas interoperables, pues la realidad del mercado es que hay muchas opciones pera muchos gustos y necesidades.

Microsoft como creador de C# y del CLR promueve la adopción de estas tecnologías en diferentes plataformas y por medio de una plataforma en la nube de capacidades inimaginables como Windows Azure Te permite y allana el camino para tener el backend ideal sin importar las plataformas en que quieras implementar tu aplicación.

Related Posts

Despierta, desarrollar apps con HTML5/JS y Azure Mobile Services es el futuro y el presente, Cómo acceder al Storage de Windows Azure Utilizando REST en Windows 8 – WinRT – Video

Lo sé porque lo debo de saber, es mi propósito.

Hola Neo, te hace falta entender con que llave puedes entrar a la Matrix?

Neo: Tú

Llave: Authorization Header

Matrix: Azure Storage

Cada vez que vamos a enviar operaciones al storage de Windows Azure debemos llenar el header de autorización, esto en primera instancia parece una tarea fácil de realizar.

De acuerdo a la documentación el header se debe elaborar de la siguiente forma:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

Revisémoslo por partes.

[SharedKey|SharedKeyLite]

Un error muy común es presumir que SharedKey es la StorageKey que tenemos en nuestra cuenta de storage de Windows Azure, esta llave si tiene que ver en el proceso pero jamás se envía como parte del header.

En la historia de Azure Storage tenemos ya el release de unas cuantas versiones, y con cambios entre una y otra versión han llegado también cambios en la forma de obtener el signature. Es decir ha cambiado el esquema de autenticación.

En el caso de Blob y Queue Storage ahora se debe incluir información adicional al momento de calcular la firma, sin embargo por temas de compatibilidad hacia atrás se permite seguir calculando la firma de la forma como se hacia anteriormente de tal forma que no dejen de funcionar las cosas que ya venían haciéndolo.

Por ello cuando hacemos operaciones con versiones anteriores a 2009-09-19 hacemos uso de SharedKeyLite (llave compartida ligera) que no es sino una versión más sencilla, menos compleja de SharedKey.

En este artículo explicare como se hace utilizando SharedKey que al ser una versión más compleja ya incorpora en si misma los cálculos para de SharedKeyLite.

SharedKeyLite es el esquema usado para utilización de TableStorage aún en la versión 2012-02-12, es decir en el caso de Table Storage no se hace uso de SharedKey.

Así las cosas el encabezado queda de la siguiente manera.

Authorization="SharedKey <AccountName>:<Signature>"

AccountName

Es el nombre de la cuenta de storage de Windows Azure que se haya creado, por ejemplo MyStorage.

Authorization="SharedKey MyStorage:<Signature>"

Signature

Tricky part

La firma se utiliza para que tanto el cliente que envía la petición como el servidor de Azure Storage puedan validar que la información recibida es confiable y proviene de una fuente segura.

Así que con la información que existe en el el cliente que realiza la solicitud se realiza una serie de cálculos para obtener una firma, y en el servidor se realizan de nuevo dichos cálculos . Si la firma resultante es la misma entonces la operación es autorizada, de lo contrario es rechazada con un código de error  403 (forbidden).

La creación de la firma se puede reducir a dos pasos

1. Crear la cadena a firmar
2. Firmar la cadena

Crear la cadena a firmar

De acuerdo a la documentación la cadena a firmar es una cadena donde se concatenan una línea tras otra con

• La operación a realizar (PUT, GET, POST,DELETE, etc)
• Una serie de encabezados http pre establecidos, cuando no se tiene alguno de los encabezados se deja la línea en blanco
• Una serie de encabezados http canónicos, esto es los encabezados adicionados al request que comienzan por x-ms-, deben concatenarse y ordenarse de manera alfabética siguiendo este patrón "x-ms-headername:value\n", si algún header x-ms-no es utilizado simplemente no hace parte de la lista y no se deja salto de línea en su lugar.
• El nombre canónico del recurso, implica escribir el  recurso que se esta accediendo en formato "/accountName/containers/blobname\parameter:value\n" siendo la última parte una lista con los parámetros utilizados cada uno con formato "parámetro:valor\n" al final de esta cadena NO hay salto de línea.

Cuando no se tiene alguno de los encabezados del segundo punto se deja la línea en blanco.

Quedando de esta forma ( los comentarios están solo por claridad , NO hacen parte de la cadena )

GET\n /*HTTP Verb*/
\n    /*Content-Encoding*/
\n    /*Content-Language*/
\n    /*Content-Length*/
\n    /*Content-MD5*/
\n    /*Content-Type*/
\n    /*Date*/
\n    /*If-Modified-Since */
\n    /*If-Match*/
\n    /*If-None-Match*/
\n    /*If-Unmodified-Since*/
\n    /*Range*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\n
x-ms-version:2009-09-19\n/*CanonicalizedHeaders*/
/myaccount/mycontainered\n
comp:metadata\n
restype:container\n
timeout:20/*CanonicalizedResource*/

Acá esta el extracto de los headers canónicos del ejemplo

x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n

Es decir cumplen con el formato "header:valor\n" y además están organizados alfabéticamente.

Este es un extracto del recurso canónico

/myaccount/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20 

Nota: en el simulador de Azure Storage el nombre de la cuenta se debe colocar dos veces en el nombre de recurso canónico, ejemplo:

/<strong>myaccount/myaccount</strong>/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20 

Si eliminamos los comentarios vemos como queda la cadena finalmente:

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/myaccount/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20

   Para tener más claridad respecto a como calcular los siguientes campos

• Que headers se deben utilizar
• Date / x-ms-date , que deben estar en formato RFC1123
• Canonicalized Headers, cuales se deben utilizar

les recomiendo revisar este enlace Put Blob (REST API)

Firmar la cadena

Ya teniendo preparada la cadena como lo vimos en el punto anterior se procede a firmarla.

De acuerdo a la documentación se debe hacer utilizando este patrón:

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

Analizándolo de adentro hacia afuera:

(UTF8(StringToSign)

dado que la misma cadena a nivel binario puede ser completamente diferente lo primero que debemos hacer es convertirla a encoding UTF8. Una vez así ya sabemos que ambos lados firmarán la misma información.

HMAC-SHA256(UTF8(StringToSign))

Esto indica que la cadena debe firmarse utilizando el algoritmo HMAC-SHA256… solo que en la documentación se ha olvidado decir algo que es SUMAMENTE IMPORTANTE:

• Para firmar una cadena con dicho algoritmo se requiere una llave de encripción simétrica
• La llave de encripción simétrica es la CLAVE DE ACCESO PRIMARIA de la cuenta de Azure Storage que se esta utilizando.

Es importante tener en cuenta que la CLAVE DE ACCESO PRIMARIA es entregada por Windows Azure expuesta como una cadena Base64.

Hacer la tarea de firmado cambia de acuerdo al lenguaje y framework que estemos utilizando.

En este artículo muestro como hacerlo fácilmente desde Windows 8 (o sea WinRT), de paso haciendo la conversión al encoding UTF 8.

Cómo usar mecanismos de firma digital en Windows 8? – WinRT

Base64(HMAC-SHA256(UTF8(StringToSign)))

Los algoritmos de cifrado – hash – signature devuelven la información en forma de información binaria que no es representable por medio de cadenas de texto, y un header de un request http requiere que la información este en texto plano.

Una de las formas de mostrar contenido binario como texto plano es utilizando el esquema de codificación Base64 técnicamente no es una cosa que aprendas a hacer en un par de minutos, pero por fortuna es tan ampliamente adoptado que todos los frameworks ya lo incluyen como funcionalidad, de tal forma que envías un conjunto de datos y obtienes una cadena en dicho formato.

Así las cosas el header de autorización puede lucir de manera muy similar a esto:

Authorization="SharedKey MyStorage:Kcb0oMaIBCLITcBJStWjNj5WN309FEhbbfIb7ocX3bE="

Ejemplo

En este artículo, tengo un video donde se explica paso por paso como hacer una operación REST para manipular el storage de Windows Azure desde Windows 8 (WinRT)y de paso muestro como elaborar el header Authorization con todo lo expuesto en este artículo incluyendo como realizar la firma digital.

Video – Cómo acceder al Storage de Windows Azure Utilizando REST en Windows 8 – WinRT – C#

Related Posts

Cómo acceder al Storage de Windows Azure Utilizando REST en Windows 8 – WinRT – Video, Cómo usar mecanismos de firma digital en Windows 8? – WinRT

 

WinRT como muchos de ustedes saben nos permite crear aplicaciones con C# , como suelo mencionar en muchos de mis cursos WinRT:

• Se programa como en .NET Framework
• Se ve como .NET Framework
• Muchos componentes se llaman igual que en el .NET Framework
• Pero WinRT NO es .NET Framework
• Por ello, hay cosas que simplemente no existen aún en WinRT o existen pero con nombres y forma de uso diferentes, ese es el caso de las API de criptografía.

Valga decir que la implementación en WinRT me parece mucho más limpia y mejor estructurada, aunque aún tiene opciones de mejora, sutiles pero que suman para hacer la diferencia.

Sin más preámbulos, en este artículo enseñare a firmar contenidos digitalmente haciendo uso de la API de criptografía, tomare como base el algoritmo HMAC SHA256, como verán el algoritmo que escojamos es irrelevante en el proceso de firmado.

Cómo firmar digitalmente la información?

Creamos un método público llamado ComputeSignature que reciba como parámetro

1. El nombre del algoritmo a utilizar
2. El contenido a firmar
3. Un valor para crear la llave
4. El tipo de encoding para el contenido

Para efectos de este post asumiremos que el contenido a firmar sea siempre de tipo string. Es importante incluir el tipo de encoding del texto porque un mismo texto puede tener una información binaria diferente de acuerdo al tipo de encoding y dado que las operaciones criptográficas utilizan datos binarios se pueden presentar diferencias al calcular la firma digital en un encoding u otro.

Por defecto el encoding manejado lo estableceremos en UTF8.

El método devuelve una cadena de texto que es la firma del contenido.

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
        
}

Agregamos referencia a los siguientes namespaces

using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;

Dentro del método inicializamos el proveedor del algoritmo con el valor enviado como parámetro, dado que como parámetro hemos recibido un enum este debemos convertirlo en string.

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
    var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
}

Ahora hay que preparar el contenido que vamos a firmar, la API de criptografía funciona utilizando información expuesta por medio de la interfaz IBuffer, así que hay que convertir la información a dicho formato, esto lo hacemos haciendo uso de la clase CryptographicBuffer la cual expone varios métodos estáticos que permiten convertir datos desde y hacia una interfaz IBuffer.

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
    var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
    var contentBuffer = CryptographicBuffer.ConvertStringToBinary(content, BinaryStringEncoding.Utf8);
}

Para lograr el proceso de la firma se requiere crear una llave criptográfica, más adelante veremos como crear una, por ahora asumamos que la llave llega como parámetro expuesta como una cadena.

Así que ahora hay que convertir la cadena en información que pueda entender la API de criptografía, es decir en forma de un IBuffer.

La llave utilizada para calcular la firma digital es una llave simétrica, por lo cual la información que contiene es información binaria que no necesariamente tiene representación como texto, dado que el método que hemos creado recibe la llave como texto debemos presumir que se trata información binaria expuesta como cadena haciendo uso de Base64, por ello utilizando CryptographicBuffer convertiremos esta cadena directamente a IBuffer.

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
    var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
    var contentBuffer = CryptographicBuffer.ConvertStringToBinary(content, BinaryStringEncoding.Utf8);
    var keyBuffer = CryptographicBuffer.DecodeFromBase64String(key);
}

Estando ya en forma de buffer creamos la llave criptográfica de acuerdo al algoritmo seleccionado:

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
    var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
    var contentBuffer = CryptographicBuffer.ConvertStringToBinary(content, BinaryStringEncoding.Utf8);
    
    var keyBuffer = CryptographicBuffer.DecodeFromBase64String(key);
    var signatureKey = algorithmProvider.CreateKey(keyBuffer);
}

Finalmente creamos la firma, esto es sencillo, en la clase CryptographicEngine existe el método Sign el cual solo requiere la llave y el contenido para firmar. Este método como pueden adivinar devuelve un IBuffer, nosotros requerimos que devuelva un string así que nuevamente hacemos uso de CryptographicBuffer pero esta vez para convertir el IBuffer a un string con la información binaria expuesta como Base64.

public string ComputeSignature(string algorithmName, string content, string key,
                               BinaryStringEncoding encoding = BinaryStringEncoding.Utf8)
{
    var algorithmProvider = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
    var contentBuffer = CryptographicBuffer.ConvertStringToBinary(content, BinaryStringEncoding.Utf8);
    
    var keyBuffer = CryptographicBuffer.DecodeFromBase64String(key);
    var signatureKey = algorithmProvider.CreateKey(keyBuffer);

    var signedBuffer = CryptographicEngine.Sign(signatureKey, contentBuffer);

    return CryptographicBuffer.EncodeToBase64String(signedBuffer);
}

Cómo crear una llave simétrica para la firma?

Para probar el método ComputeSignature debemos enviar como parámetro una llave de cifrado.

Las llaves no pueden ser de un tamaño escogido por capricho, cada algoritmo tiene algunas restricciones para el  tamaño de llave que requiere.

CryptographicBuffer también posee un método GenerateRandom el cual nos permite crear material para la llave. Es decir sino tenemos llaves simétricas podemos generar las propias de la siguiente manera:

private string GenerateMacSimetricKey(string algorithmName)
{
    var alg = MacAlgorithmProvider.OpenAlgorithm(algorithmName);
    var keyBuffer = CryptographicBuffer.GenerateRandom(alg.MacLength);
    return CryptographicBuffer.EncodeToBase64String(keyBuffer);
}

Cómo verificar un contenido firmado?

La forma de verificar una firma es en efecto volviendo a calcular la firma, si la cifra calculada es igual a la firma con que ha llegado la información entonces la información es correcta y no ha sido modificada.

WinRT tiene ya incorporado un método para verificar la firma, en la clase CryptographicEngine esta el método VerifySignature, este, como es de esperarse, requiere como parámetros datos de tipo IBuffer y CryptographicKey, si ya los tienes a la mano usar esta alternativa es bastante eficiente, pero si por el contrario tienes la llave en cualquier otro formato y debes convertirla a CryptographicKey no tendrás ninguna ventaja respecto a calcular nuevamente la firma ya que debes hacer prácticamente la misma cantidad de operaciones en código.

Ejemplo de uso

Creamos un método Test para realizar las pruebas.

En el creamos el contenido que deseamos firmar, y generamos una llave para realizar dicha firma.

        public void Test()
        {
            var contenido = @"Nombre:Juan Carlos Ruiz Pacheco
CC:79919051
Profesión:Ingeniero de Sistemas
Nacionalidad:Colombiano";

            var alg = MacAlgorithmProvider.OpenAlgorithm(MacAlgorithmNames.HmacSha256);
            var signatureKey = GenerateMacSimetricKey(MacAlgorithmNames.HmacSha256);
            Debug.WriteLine(string.Format("This is the signature key:{0}", signatureKey));

            var signature = ComputeSignature(MacAlgorithmNames.HmacSha256, contenido, signatureKey);
            Debug.WriteLine(string.Format("This is the computed signature:{0}", signature));
        }

Salida:

This is the signature key:kbKOyOBMP8MHMDQ2Gtnn1HXgAXDjcuFOAcOzE+fnS2I=
This is the computed signature:Kcb0oMaIBCLITcBJStWjNj5WN309FEhbbfIb7ocX3bE=

Eso es todo, espero que el artículo les sea de utilidad

Related Posts

No related posts.

Aprende a utilizar el servicio de cloud storage de Windows Azure utilizando la API REST.

Esto puede ser muy útil cuando no puedes usar Windows Azure SDK o cuando no hay una versión del SDK disponible para el lenguaje o plataforma que manejas.  

El video se hizo en WinRT + C# pero el mecanismo puede ser imitado desde otros lenguajes y frameworks.
En este video también se muestra como construir el header de autorización incluyendo como crear la firma con el Storage Key.

Aprende a utilizar el servicio de cloud storage de Windows Azure utilizando la API REST.

Esto puede ser muy útil cuando no puedes usar Windows Azure SDK o cuando no hay una versión del SDK disponible para el lenguaje o plataforma que manejas.  

El video se hizo en WinRT + C# pero el mecanismo puede ser imitado desde otros lenguajes y frameworks. 
En este video también se muestra como construir el header de autorización incluyendo como crear la firma con el Storage Key.

Este es el código fuente

using System;
using System.Globalization;
using System.IO;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading.Tasks;
using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;

namespace App5.Storage
{
    public class BlockBlobStorage
    {
        private const string X_MS_BLOCK_BLOB = "BlockBlob";
        private const string X_MS_VERSION = "2012-02-12";
        public string Account { get; set; }
        public string Key { get; set; }

        public BlockBlobStorage(string account, string key)
        {
            Account = account;
            Key = key;
        }

        public async Task<HttpResponseMessage> UploadAsync(string blobname, Stream stream,
            string mimetype = "application/octect-stream")
        {
            var httpClient = new HttpClient();
            var content = new StreamContent(stream);
            var tmpdate = RFC1123DateTime;
            //headers
            content.Headers.ContentType = new MediaTypeHeaderValue(mimetype);
            httpClient.DefaultRequestHeaders.Add("x-ms-date", tmpdate);
            httpClient.DefaultRequestHeaders.Add("x-ms-blob-type", X_MS_BLOCK_BLOB);
            httpClient.DefaultRequestHeaders.Add("x-ms-version", X_MS_VERSION);

            string signature = CreateSignature(
                HTTPVerb: "PUT",
                ContentLength: stream.Length.ToString(),
                ContentType: mimetype,
                CanonicalizedHeaders: "x-ms-blob-type:BlockBlob\nx-ms-date:" + tmpdate + "\nx-ms-version:2012-02-12",
                CanonicalizedResource: string.Format("/{0}/{1}", Account, blobname)
                );

            httpClient.DefaultRequestHeaders.Add("Authorization",
                string.Format("SharedKey {0}:{1}", Account, signature));

            return await httpClient.PutAsync(
                string.Format("http://{0}.blob.core.windows.net/{1}", Account, blobname),
                content
                );
        }

        private string CreateSignature(
            string HTTPVerb = "",
            string ContentEncoding = "",
            string ContentLanguage = "",
            string ContentLength = "",
            string ContentMD5 = "",
            string ContentType = "",
            string Date = "",
            string IfModifiedSince = "",
            string IfMatch = "",
            string IfNoneMatch = "",
            string IfUnmodifiedSince = "",
            string Range = "",
            string CanonicalizedHeaders = "",
            string CanonicalizedResource = ""
            )
        {
            var sumstring = string.Format("{0}\n{1}\n{2}\n{3}\n{4}\n{5}\n{6}\n{7}\n{8}\n{9}\n{10}\n{11}\n{12}\n{13}",
                HTTPVerb, ContentEncoding, ContentLanguage, ContentLength, ContentMD5,
                ContentType, Date, IfModifiedSince, IfMatch, IfNoneMatch, IfUnmodifiedSince,
                Range, CanonicalizedHeaders, CanonicalizedResource
                );

            return ComputeHMAC_SHA256(sumstring);
        }

        private string ComputeHMAC_SHA256(string input)
        {
            var alg = MacAlgorithmProvider.OpenAlgorithm("HMAC_SHA256");
            //preparar input
            var inputBuffer = CryptographicBuffer.ConvertStringToBinary(input, BinaryStringEncoding.Utf8);
            //preparar key
            var keybuffer = CryptographicBuffer.DecodeFromBase64String(Key);
            var hmacKey = alg.CreateKey(keybuffer);

            var signbuffer = CryptographicEngine.Sign(hmacKey, inputBuffer);
            return CryptographicBuffer.EncodeToBase64String(signbuffer);
        }

        public string RFC1123DateTime { get { return DateTime.UtcNow.ToString("R", CultureInfo.InvariantCulture); } }
    }
}

         var file = await StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///Assets/chocorramo.jpg"));
    var stream = await file.OpenStreamForReadAsync();

    var blobUploader = new BlockBlobStorage("jk4freeusage", "Yk4KMu8b0FAzCuqJf4y3j5XSslLxqXYndfkReWg8YkLFVaQOzF1Ga4eAE8jy+rEyOMh9RP228rz0SB2uwkoOoQ==");
    var rta = await blobUploader.UploadAsync("imagenes/chocorramo.jpg", stream, mimetype: "image/jpeg");

Acá disponible desde GitHub

Saludos

Related Posts

Cómo detectar si hay conexión a Internet en WinRT C#, El extraño caso del WebView que siempre mantiene visible sobre los demás controles – WinRT – C#, Mostrar colores de documentos RTF al cargarlos en un RichEditBox – WinRT – C#, El control RichEditBox no muestra le formato de los documentos RTF aunque esten bien formados – WinRT – C#, Acceder a los archivos de instalación en aplicaciones Windows Store

Multipliquemos esa complejidad por un conjunto de servicios en la nube disponibles en tiempo real  para miles de usuarios y donde la fecha ( con horas , minutos y segundos) son el componente fundamental de la lógica de funcionamiento… sino se maneja un formato único de hora puede ser un verdadero apocalipsis.

Para evitar este tipo de problemas existe RFC1123 – Time format. RFC es la sigla de Request For Comments, es decir no es propiamente un estándar pero si esta muy cerca de serlo, y en el caso de RFC1123 podemos hablar de un estándar de facto al menos en cuanto a fechas se refiere.

Utilizando la información de fechas según este RFC nos evitamos muchos problemas en aplicaciones localizadas, ya que independientemente del Cliente donde se despliegue la UI, en el backend tenemos un formato de fecha ampliamente conocido y soportado por la mayoría de desarrolladores y herramientas a  nivel mundial.

El RFC1123 establece un formato de fecha independiente de la cultura y localización

• La hora siempre se menciona respecto a la hora del meridiano de Greenwich (Greenwich Mean Time)
• Los meses siempre son abreviaciones en inglés de la siguiente manera: "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
• Los días siempre son abreviaciones en inglés de la siguiente manera: "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"

Este es un ejemplo de fecha en RFC1123:  “Mon, 19 Nov 1979 10:45:00 GMT”.

En la plataforma de Windows Azure este es el formato de fecha utilizado para realizar llamadas a través de sus API’s expuestas por REST, esto es, cada vez que hacemos uso de los headers

• Date
• x-ms-date

Debemos asignarles una cadena que representa una fecha en RFC1123.

En C# podemos conseguir una fecha representada en una cadena RFC1123 de la siguiente forma:

  
//obtenemos la fecha o el offset de fecha según sea el caso  
var dateTimeOffsetUtcNow = DateTimeOffset.UtcNow;  
//obtenemos cadena con formato RFC1123  
string utcDateInRfc1123Format = dateTimeOffsetUtcNow.ToString("R", CultureInfo.InvariantCulture);  

Related Posts

No related posts.

Pero a veces sucede que el compilador detecta algo que es falso, cuando?

Si estamos por ejemplo utilizando un campo de manera dinámica no hay manera que el compilador se entere que este ha sido utilizado, es probable que el compilador crea que nunca lo estamos usando aunque realmente lo estamos usando todo el tiempo.

En estos casos puede resultarte agradable desactivar dicho Warning, para el primer caso basta con encerrar la definición del campo en el pragma “warning disable ###” siendo ### el número del warning que parwa este caso es el 0169, ejemplo:

#pragma warning disable 0169  
int unusedField;  
#pragma warning restore 0169

Como te darás cuenta hay que restaurar las cosas a su estado inicial puesto que la sentencia pragma habilita o deshabilita el warning para todo el archivo actual.

Related Posts

No related posts.