martes, 20 de diciembre de 2011

Certificados, ficheros y claves privadas

Últimamente por motivos relacionados con mi trabajo me he tenido que ir introduciendo cada vez más y más en el mundo de la seguridad informática. Es un campo muy extenso e interesante pero también un tanto oscuro en algunos puntos. (sobre todo si no das con las fuentes de información adecuadas)

En este ecosistema de seguridad, como ya conocemos todos en mayor o menor medida, los certificados de seguridad juegan un papel de lo más importante. ¿Quien no ha oído hablar de los certificados X509?

Windows incluye una herramienta para gestionar los certificados que tenemos instalados en la máquina/máquinas. Más concretamente es un complemento de la Microsoft Management Console (a.k.a. navaja suiza) llamado “Certificates”. Esta herramienta es de lo más conocida y podéis encontrar mucha documentación sobre ella en el MSDN, por ejemplo aquí.

Curioseando con la instalación de los certificados me surgió la pregunta sobre donde Windows almacena la clave privada de los mismos. Leyendo una poco al respecto, encontré una herramienta que nos aporta dicha información llamada Find Private Key Tool.

Dicha herramienta nos permite a través de la línea de comandos, preguntar sobre un determinado certificado ( filtrando por diferentes características como su subject, thumbprint…). En caso de existir un certificado que se adapte a los parámetros solicitados,  nos retornara el nombre del fichero que le da soporte. Esta información nos puede ser necesaria en caso de tener que ajustar los permisos de las acciones que sobre el mismo se deben permitir. El caso más típico es acceder a la clave privada de un certificado (por código) con un usuario con permisos restringidos (por ejemplo el application pool identity de una aplicación ASP.NET)

Según la especificación de la herramienta:

  1: Usage: FindPrivateKey <storeName> <storeLocation> [{ {-n <subjectName>} | {-t <thumbprint>} } [-f | -d | -a]]
  2:        <subjectName> subject name of the certificate
  3:        <thumbprint>  thumbprint of the certificate (use certmgr.exe to get it)
  4:        -f            output file name only
  5:        -d            output directory only
  6:        -a            output absolute file name

Ejemplos de comandos:


Buscar en StoreName “My”  y Store Location “CurrentUser” un certificado con el Subject  CN=TESTCERT (CN es el Common Name, que forma parte del Subject)

  1: FindPrivateKey My CurrentUser -n "CN=TESTCERT"

Buscar en StoreName “My” y Store Location “LocalMachine” un certificado con el Thumbprint pasado por parámetro

  1: FindPrivateKey My LocalMachine -t "40 ee 7b 2f 10 59 38 99 4f 65 9f 8f 92 38 85 a3" –c

En caso de que el certificado solicitado exista, la herramienta nos devolverá algo como:

  1: Private key directory:
  2: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
  3: Private key file name:
  4: <GUID>

Siendo el GUID el nombre del fichero asociado que almacena la clave privada. Una vez localizado podemos modificar sus permisos si para alguno de nuestros procesos esto es necesario.

jueves, 21 de julio de 2011

Retrospective [Evento: SCRUM y conceptos ágiles]]


El pasado día 19 de Julio dentro del marco WebDev Bilbao tuve la suerte de dar una charla sobre SCRUM y conceptos ágiles. Me gustaría realizar una pequeña retrospectiva del mismo y sacar algunas conclusiones:

  • Presencia
    Lo primero que me llamó al atención fue la buena acogida del evento en la comunidad. Superó en número todas las expectativas, más teniendo en cuenta, que la charla fue de 19:00 a 21:00 en un día de verano (que cayese el diluvio universal igual ayudó...)
    Se confirma, una vez más, que la inquietud por las metodologías ágiles es grande, la tendencia cada vez mayor.
  • Perfiles
    Entre los asistentes existían diferentes perfiles. Hubo gente con mucha experiencia en gestión y gente más joven. La combinación de todos ellos nos ayudo a completar la foto desde diferentes perspectivas. Comprobamos una vez más, que las bondades de SCRUM lo son tanto para los gestores como para los desarrolladores. A golpe de empatía llegamos rápidamente a acuerdos.

    Aun así, algunos perfiles se echaron de menos. No hubo presencia (al menos hasta donde yo pude comprobar) de ningún Tester o QA. Su integración en los equipos es un punto muy interesante por lo que me hubiera gustado contar con alguien que aportase dicha visión.
    También noté la falta de diseñadores Web o gráficos. Este es un perfil que tiene presencia en WebDev Bilbao y que tiene una integración particular en los equipos de desarrollo. También eché en falta su voz.

    Otra vez será...(o eso espero!)
  • Empresas pequeñas, startups...
    Bilbao es una zona de emprendedores. Combinado con las “facilidades” de nuestro sector la presencia de startups y microempresas es muy significativa en este tipo de actividades. Los profesionales de este tipo de empresas están especialmente sensibilizados con aspectos como el trato al cliente, time to market... Además necesitan más que nadie dedicar su capacidad (más limitada que en empresas más grandes) a los aspectos que realmente aportan valor.

    Por otro lado, también discutimos sobre por dónde empezar en una empresa más grande y como concienciar a los gestores más reaccionarios sobre las bondades de la agilidad.
  • Poco conocimiento previo sobre SCRUM
    Algo que me sorprendió, es que muchos de los profesionales que acudieron no conocían nada o casi nada acerca de SCRUM. Quizás deba ampliar mi circulo de colegas, puesto que mi percepción estaba, me temo, distorsionada...

    Es importante para evitar que la brecha se siga abriendo realizar ciertas acciones de iniciación a las metodología ágiles orientadas a sentar las bases sobre las cuales podamos autoformarnos o elegir el sabor que mejor nos encaje.


Resumiendo, creo que el balance de la actividad es muy positivo. Ha quedado patente el interés que los desarrolladores, manager y demás stakeholder tienen por mejorar a través de la agilidad.
Desde el grupo de Agilidad y gestión de proyectos de WebDev Bilbao tomamos nota y continuaremos trabajando en otras actividades. Con algunas de ellas intentaremos profundizar más en aspectos que ya hemos ido tocando, como por ejemplo, gestión de contratos ágiles, liderazgo, documentación...(sí puede haberla!!)

También intentaremos abrir otras líneas como una introducción al Kanban o confrontar las metodologías ágiles con otras más predictivas, que no solo de SCRUM vive el hombre.

Por supuesto, si eres, trabajas o pasas por Bilbao no dudes en pasarte por el WebDev Bilbao que serás bienvenido!

Por cierto, os podéis descargar la presentación de la charla de aquí (hay más cosas en Prototypes, cotillea al gusto ;))

miércoles, 13 de julio de 2011

Evento: SCRUM y conceptos ágiles

El próximo día 19 de Julio, tengo el placer de dar una charla sobre SCRUM y conceptos ágiles dentro del marco de actividades del grupo WebDev Bilbao. En ella, explicaré algunos conceptos claves sobre agilidad y analizaremos las propuestas de SCRUM sobre como afrontarlos.

A quien va dirigido

  • Gestores de proyectos de desarrollo de Software.
  • Product mangers y Stakeholders interesados en agilidad.
  • Por supuesto, desarrolladores!

Fecha y hora:

  • 19 de Julio de 2011 a las 19:00
  • Eutokia (Centro de Innovación Social de Bilbao)

Nota:
Aunque en principio el acceso a estos eventos está restringido a la gente del grupo de WebDeb Bilbao, si quieres pasarte puedes enviarme un correo electrónico a andoni.arroyo@gmail.com y veremos que podemos hacer ;)

viernes, 8 de julio de 2011

Silverlight y las excepciones no gestionadas

Silverlight nace para cubrir las necesidades de aplicaciones RIA, y como sabemos, las aplicaciones de Internet son exigentes en muchos aspectos. Es debido a dicha concepción, que posee ciertas características muy interesantes para escenarios para los que originalmente no fue creado.

Por ejemplo, la huella en memoria de Silverlight es sensiblemente menor que incuso para el .NET Framework Client Profile. Además el tamaño del instalador es también varias veces menos que dicho (de 28MB a 6MB ). Estos detalles que nos pueden parecer banales, no lo son tanto, si multiplicamos dichas diferencias por muchos millones de descargas o requerimientos de Hardware…

Teniendo en cuenta estas ventajas y que las partes más comunes de WPF se encuentra también presente en Silverlight, este se presenta como un candidato válido para desarrollo de aplicaciones de escritorio. (Ahora que está tan de moda HTML5/JS…)

Este modo de trabajo se conoce como “out of browser” (OOB). Tengamos en cuenta que la misma aplicación puede ejecutarse dentro y fuera del navegador, en principio, en base a que el usuario decida instalarla.

Si deseamos desarrollar aplicaciones de escritorio, podríamos distribuir nuestro .xap como parte del instalador de la aplicación completa, evitando dar la posibilidad de ejecutarla en el navegador (El host va a ser el sllauncher.exe)

Las mayores restricciones en este aspecto están relacionadas con la interacción con el Sistema Operativo y acceso a recursos de la máquina local. Si vuestro conjunto de requisitos de interacción en el puesto cliente no son muy elevadas, es posible que Silverlight pueda ser vuestra tecnología de cliente.

En esta forma de trabajo, debemos evaluar la conveniencia de algunos de los planteamientos del equipo de Microsoft y adaptarlos a nuestras necesidades. La gestión predeterminada de las excepciones no gestionadas que nos propone Visual Studio no está pensada si deseamos crear una aplicación de escritorio.

Si vemos el código que nos propone el Visual Studio al crear el proyecto de Silverlight observamos:

  1:         private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
  2:         {
  3:             // If the app is running outside of the debugger then report the exception using
  4:             // the browser's exception mechanism. On IE this will display it a yellow alert 
  5:             // icon in the status bar and Firefox will display a script error.
  6:             if (!System.Diagnostics.Debugger.IsAttached)
  7:             {
  8:
  9:                 // NOTE: This will allow the application to continue running after an exception has been thrown
 10:                 // but not handled. 
 11:                 // For production applications this error handling should be replaced with something that will 
 12:                 // report the error to the website and stop the application.
 13:                 e.Handled = true;
 14:                 Deployment.Current.Dispatcher.BeginInvoke(delegate { ReportErrorToDOM(e); });
 15:             }
 16:         }
 17:
 18:         private void ReportErrorToDOM(ApplicationUnhandledExceptionEventArgs e)
 19:         {
 20:             try
 21:             {
 22:                 string errorMsg = e.ExceptionObject.Message + e.ExceptionObject.StackTrace;
 23:                 errorMsg = errorMsg.Replace('"', '\'').Replace("\r\n", @"\n");
 24:
 25:                 System.Windows.Browser.HtmlPage.Window.Eval("throw new Error(\"Unhandled Error in Silverlight Application " + errorMsg + "\");");
 26:             }
 27:             catch (Exception)
 28:             {
 29:             }
 30:         }

Como vemos se incluye una función para interactuar con el DOM. Esto no tiene sentido si nuestra aplicación va a correr siempre en modo OOB. Además comprueba si no tenemos el depurador adjunto para realizar esta notificación…

Vamos a comenzar a modificar este comportamiento para que se adapte a nuestras necesidades.


Lo primero vamos a hacer es cambiar el código del método Application_UnhandledException y eliminar la función ReportErrorToDOM.

El resultado quedaría algo así:

  1:         private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
  2:         {
  3:             e.Handled = true;
  4:             new ExceptionDetailView {DataContext = new ExceptionDetailViewModel(e.ExceptionObject)}.Show();
  5:         }


Sencillo, verdad?


Antes de nada marcamos como tratado el parámetro recibido para notificar que ya ha sido tratada y que no escale más por la pila de excepciones. Además mostramos un mensaje de error por pantalla notificando al usuario que se ha producido un error.

Este sería un punto interesante para guardar en el log de la aplicación la información más detallada de la excepción, que seguro el departamento de soporte nos lo agradecerá.

Si deseáis incluir una buena gestión de log en Silverlight os recomiendo usar el Silverlight Integration Pack for Microsoft Enterprise Library 5.0.


Ahora la pregunta es que es ExceptionDetailView?


Pues no es más que una vista que creamos para mostrar el mensaje de error de manera agradable para el usuario. La particularidad de la misma, es que es una ChildWindow clase que se incluye en Silverlight desde la versión 3.


Esta clase nos permite colocar un control de usuario simulando una ventana modal. Es decir, deshabilita y oscurece el fondo. Este es el comportamiento que deseamos para mostrar nuestra excepción de modo que quede algo como esto:


image


En la implementación de la vista empleamos el patrón MVVM, sobre el cual existen toneladas de información. (y eso en raras ocasiones es bueno…)

Resumiendo podemos decir que disponemos de un ViewModel (ExceptionDetailViewModel.cs) y una vista que se encarga de pintar los datos que ese ViewModel expone por pantalla. (ExceptionDetailView.xaml)

La vista tiene asociada en su DataContext el ViewModel y vía Binding implementamos el conexión entre los datos y su representación gráfica.

Además de los datos es responsabilidad del ViewModel exportar la funcionalidad (vía comandos) que la vista puede invocar. En este caso, nuestro ViewModel expone un comando a la vista (ToggleShowingExceptionDetailCommand) que le permite mostrar u ocultar la información detallada de la excepción, para contentar a los más curiosos…

Pues ya solo queda probar, porque nos encanta probar, verdad??


Y en este caso debemos lanzar una excepción (al gusto, yo me he decantado por una IndexOutOfRangeException) y comprobamos que la aplicación muestra el mensaje de error de manera correcta en vez de quedarse en blanco.


Espero que os resulte interesante la idea y os incluyo el código fuente de la aplicación de ejemplo para que podáis probar su funcionamiento. Podéis consultar este y otros prototipos aquí (el nombre del archivo de esta solución es Andoni.Arroyo.UnhandledException )

sábado, 25 de junio de 2011

Evolución del Thread Local Storage (a.k.a. TLS)

Una de las cosas que más me gusta de .NET es lo rápido y consistente que evoluciona. Cuando cubre alguna funcionalidad, lo hace de manera elegante y bien terminada. Como desarrolladores es un gusto consumir las clases que exponen dicha funcionalidad y la experiencia suele ser de lo mas gratificante.

Nuestra responsabilidad como desarrolladores es conocer lo que nos brinda y aprovechar al máximo las ventajas que dichas evoluciones nos aportan. Esto nos permite centrar nuestros esfuerzos en las tareas que más valor aportan delegando en el framework las tareas más rutinarias y que aun siendo necesarias no dan valor al producto.

Un ejemplo de estas mejoras, incluida en el Framework 4 cubre un escenario más común de lo que parece, como es implementar un thread-local storage, conocido como TLS.

Imaginemos que deseamos realizar ciertas tareas en paralelo. Común, verdad? Además imaginemos que para el correcto procesamiento de esas instrucciones cada uno de los hilos necesita manejar sus datos de manera separada de los demás hilo de procesamiento que ejecuta un mismo código. Esto es, cada hilo en el que se están procesando las instrucciones, dispone de una copia propia y separada de los recursos que necesita para dicho procesamiento.

Esta característica es interesante si por ejemplo exponemos cierta funcionalidad a través de un Singleton (o un conjunto determinado de instancias), pero necesitamos permitir que dicho código pueda ser invocado desde diferentes hilos. También puede ser interesante si trabajamos con algún recurso no manejado que no soporte MTA (como la implementación del COM Interop de Silverlight, por ejemplo…) o si tenemos un código heredado que deseamos modificarlo para soportar ciertas características de procesamiento en paralelo, aplicando los mínimos cambios posibles.

Para cubrir esta funcionalidad desde el .NET Framework 1.1 existe el atributo [ThreadStatic] que brinda una forma elegante de implementarlo.

Veamos con un poco de código:

  1: ...
  2: 
  3: internal class TLSTestClass
  4: {
  5:     private ClassWithHeavyProcess tp;
  6: 
  7:     internal void Test()
  8:     {
  9:         //UI Thread
 10:         tp = new ClassWithHeavyProcess();
 11:         tp.HeavyMethod();
 12: 
 13:         var bw = new BackgroundWorker();
 14:         bw.DoWork += BwDoWork;
 15:         bw.RunWorkerAsync();
 16: 
 17:         var bw2 = new BackgroundWorker();
 18:         bw2.DoWork += Bw2DoWork;
 19:         bw2.RunWorkerAsync();
 20:     }
 21: 
 22:     void BwDoWork(object sender, DoWorkEventArgs e)
 23:     {
 24:         tp.HeavyMethod();
 25:     }
 26: 
 27:     void Bw2DoWork(object sender, DoWorkEventArgs e)
 28:     {
 29:         tp.HeavyMethod();
 30:     }
 31: }
 32: ...

Veamos como implementar la clase ClassWithHeavyProcess.

Como primera aproximación podemos hacer algo así:

  1:  internal class ClassWithHeavyProcess
  2:     {
  3:         [ThreadStatic]
  4:         public static NeededForThreadProcess _neededForThreadProcess;
  5:         
  6:         static ClassWithHeavyProcess()
  7:         {
  8:             _neededForThreadProcess = new NeededForThreadProcess { Name = "Andoni" };
  9:         }
 10: 
 11:         public void HeavyMethod()
 12:         {
 13:             _neededForThreadProcess.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
 14:         }
 15:     }

Uno de los problemas de esta implementación, es que la inicialización de la variable, al estar implementada en el constructor estático solo se ejecuta una vez. Este escenario nos funcionará solo para el primer hilo, puesto que todos los demás accederán a dicha variable con un valor por defecto del tipo (nulo en los tipos por referencia).

Si no tenemos en cuenta esta circunstancia podemos obtener una bonita System.NullReferenceException como la obtiene el código aquí mostrado…


Como a grandes males, grandes remedios, podemos crearnos una propiedad que encapsule el acceso al campo e inicializarlo si está a nulo, es decir, si estamos en un hilo que no posee su propia copia de la variable.

Entonces tendríamos algo así:

  1:  internal class ClassWithHeavyProcess
  2:     {
  3:         [ThreadStatic]
  4:         public static NeededForThreadProcess _neededForThreadProcess;
  5: 
  6:         public NeededForThreadProcess NeededForThreadProcess
  7:         {
  8:             get
  9:             {
 10:                 if (_neededForThreadProcess == null)
 11:                     _neededForThreadProcess = new NeededForThreadProcess();
 12:                 return _neededForThreadProcess;
 13:             }
 14:         }
 15: 
 16:         public void HeavyMethod()
 17:         {
 18:             NeededForThreadProcess.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
 19:         }
 20:     }
Tened en cuenta que cuando un hilo completa su procesamiento es eliminado y liberados sus recursos, incluida la copia de la variable asociada. (Si el GC ha decidido llevárselos al más allá…).

Bueno, esto es así casi siempre…

Recordad que desde el .NET Framework 2.0 existe el ThreadPool. De las optimizaciones que el .NET Framework haga sobre el pool de hilos manejados también nuestras aplicaciones se verán beneficiadas, puesto que si reutilizamos los hilos también sus variables de almacenamiento local. Esto es una mejora en el rendimiento, pero debemos asegurarnos que inicializamos correctamente las variables al inicio del procesamiento, puesto que pueden ser parte de algún hilo reciclado.

Si os preguntáis porque os cuento esto, tened en cuenta que si revisáis la implementación de la clase TLSTestClass podéis comprobar que está empleando objetos BackgroundWorker  que internamente negocian con el ThreadPool de .NET.


Con respecto a este escenario el .NET Framework 4 ha evolucionado para hacernos las cosas aún más fáciles. Se ha incluido la clase genérica ThreadLocal (que ya existía en Java, sí…) que se encarga de encapsular el poco “pipeline” que nos quedaba por hacer a nosotros.

Con ella podemos evitar la propiedad y especificar el constructor que deberá invocar cuando lo necesite.


Con esta clase nuestro código podría quedar tan elegante como este:

  1:  internal class ThreadProcess
  2:     {
  3:         ThreadLocal<NeededForThreadProcess> NeededForThreadProcess = new ThreadLocal<NeededForThreadProcess>(() => new NeededForThreadProcess());
  4: 
  5:         public void HeavyMethod()
  6:         {
  7:             NeededForThreadProcess.Value.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
  8:         }
  9:     }

Realmente elegante!


Si implementáis esta funcionalidad porque desde la clase NeededForThreadProcess gestionáis algún recurso no manejado (uno de los escenarios que comentaba antes), recordad que es responsabilidad vuestra liberad dichos objetos. Esto lo debéis realizar al menos al destruir los objetos (sino antes) que los consumen, pero eso, como el valor en la mili, se os supone..