Los clientes pueden llegar a ser una inspiración, porque algunas veces te hacen preguntas cuyas respuestas te hacen pensar, estudiar y ordenar conceptos.

Aquí tengo una interesante……

De todos los aspectos necesarios para implantar una solución de autorización basada en roles ¿Qué debo hacer sí o sí?

Para lograr un correcto uso por ejemplo de Azman como herramienta de autorización basada en roles (RBAC) es necesario hacer un diseño del modelo de autorización que se desea implementar.

Esto es definir los principales aspectos que cruzan a todas las aplicaciones, que permitan a los diferentes equipos de desarrollo un uso natural de Azman dentro de las nuevas aplicaciones que desarrollen. Algunos de los aspectos a definir son:

• Administración de Roles en la organización.

La ingeniería de roles para RBAC es el proceso de definición de roles, permisos y asignación de permisos para cada role. Esto es esencialmente un proceso de ingeniería de requerimientos de roles (RE). La ingeniería de roles es el primer paso hacia la implementación de un sistema RBAC.

•  Mantención operativa del PROVISIONING

Dentro de las actividades de mantención operativa se encuentra el concepto de PROVISIONING. Esto es el proceso de asegurar que, en todo momento durante la carrera con un empleador, el personal tenga todos los privilegios de acceso necesarios, equipamiento y otros recursos de IT que pueda necesitar. Administrar esto acertada y eficientemente puede ser extremamente difícil, pero AzMan puede ayudar en gran medida, apoyando el proceso de permitir el acceso a sistemas y aplicaciones empresariales como particulares.

•  Mantención operativa Delegación de la administración

Para poder realmente cumplir con el objetivo de bajar los costos de operación es necesario poder delegar la administración de las aplicaciones. Esto ayuda también a mejorar la calidad de servicio a los usuarios cuando solicitan cambios de roles y permite administrar muchas aplicaciones de manera federada. La delegación se hace a nivel de STORE de AZMAN. Un STORE almacena una o más aplicaciones.

•  Mantención operativa Auditoria

Con Authorization Manager se pueden tener dos clases de auditoría, en tiempo de ejecución (runtime auditing) y control de cambios de authorization store (change auditing). Cuando se habilita runtime auditing, las aplicaciones generan auditorias al utilizar las políticas que están definidas en el authorization store. Se puede configurar esta auditoría para controlar los éxitos, las fallas o ambos. Esta auditoría graba en un log los clientes de contexto y los controles de acceso (access checks).

Cuando se habilita authorization store change auditing, las auditorias son generadas cada vez que el authorization store es modificado. La auditoria guarda todos los eventos, éxitos y fallas.

Un cliente que está súper entusiasmado con utilizar WCF en sus aplicaciones me preguntó….

“¿Tienes un link donde pueda ver la info de WCF?”

Yo pensé en buscarle algo en Microsoft.com, para eso me fui a GOOGLE y encontré está página que está buenísima, le tenemos que dar las gracias a Brent Sheets

Vista Series: Windows Communication Foundation

Un cliente me pregunta

¿Cómo podemos implementar seguridad en las comunicaciones desde una aplicación móvil?
El escenario es:
1.- Dispositivos móviles con Windows Mobile 5.0 / Compaq Framework
2.- Las aplicaciones consumen servicios Web.
3.- Usan una res GRPS para comunicarse con Internet.

Bueno, la respuesta por defecto es aplicar seguridad a nivel de comunicaciones. Es decir usar HTTPS para consumir los servicios Web del servidor de la aplicación. Esto puede complementarse con una VPN sobre la GPRS, pero ojo con lo lenta que se pondrán las comunicaciones. No es recomendable por la latencia que se agregará en la red.

Siguiendo con el recorrido de los mensajes, estos deben ir desde el proveedor de comunicaciones hasta la red del cliente dónde están los servicios Web. Ese tramo debe ser hecho a través de una VPN, para asegurar esa parte del canal.

Eso es todo a nivel del canal, pero si se fijan no es suficiente. Es necesario incorporar a nivel de las aplicaciones. Para esto el siguiente link es una buena introducción a nivel general.

http://www.microsoft.com/latam/technet/articulos/articulos_seguridad/2007/enero/sm0107.mspx

Ahora, lo mejor sería aplicar en las llamadas a los servicios Web WS-Security. El problema es que no viene como una posibilidad en la plataforma, por lo que hay que buscar alternativas. Una de ellas es está hecha por un MVP para CF.

http://www.brains-n-brawn.com/default.aspx?vDir=cfwse2

Otra opción complementaria la encuentran en el Webservice2 hecho por OpenNetCF
http://www.opennetcf.com/KnowledgeCenter/Library/tabid/94/Default.aspx/OpenNETCF.Web.Services2.html

Salu2

En Reporting Services (SSRS) se tiene la capacidad de agregar filtros a los reportes con relativa sencillez.

Ahora, si se tienen tres filtros los cuales estan relacionados entre sí y se quiere que al cambiar uno, el contenido de los otros cambien se debe hacer un pequeño e ingenioso truco.

En este articulo aparece cómo hacerlo.

Filtros en Cascada

Me pregunta un cliente si el error 403 es de la aplicación que le hemos construido o no.

El error 403 es un error de permisos sobre una aplicación. En rigor no es un error de la aplicación sino de la configuración de los accesos a está. Existen sub tipos de errores de acceso, los cuales se muestran en la siguiente lista.

Este error ocurre típicamente cuando el IIS no recibe junto con el Request las credenciales del usuario apropiadas.

Típicamente este error ocurre cuando es llamado un directorio que no tiene permisos de “Script Access”. Por ejemplo si se llama a una URL de está forma:

http://liarjo.spaces.live.com/

Si no se ha definido un documento por defecto (Enable Defualt Document) para ese directorio, el IIS interpreta que el cliente quiere ver los archivos que contiene ese directorio. Es entonces cuando ocurre el error 403 porque por defecto los directorios de IIS no tienen habilitado “Script Access”.

La solución para esto es:

A.- Definir un documento por defecto para ese directorio.

B.- Permitir “Script Access”.

Cuando se hace el Deploy de una aplicación, claramente la solución es la alternativa A u no la B.

En IIS la configuración de la primera opción se hace en la consola de administración.

La siguiente imagen muestra dónde se hace.

La segunda opción, “Script Access” se configura en la pestaña “Virtual Directory”, como se muestra en la segunda imagen.

Un cliente me pidió que hiciéramos un reporte utilizando Reporting Services que mostrara información de gestión de sus obras y proyectos.

La idea es que dependiendo del rol los usuarios tengan acceso a diferente información. Analysis Services (SSAS) combinado con Reporting Services puede hacer esto sin necesidad de programar si se definen roles y se configuran los permisos en SSAS Services.

Hasta ese momento todo bien, el problema surge porque no se administran los permisos usando roles AD, por lo que no se pueden mapear a SSAS directamente.

El cliente tiene una base de datos donde maneja los permisos.

Solución

Incluir en los procesos de carga del cubo una tarea de sincronización de permisos. Lo que debe hacer está tarea es:

Ø Leer los permisos desde la base de datos.

Ø Actualizar los roles y asignarlos en Analisys Server.

Para esto se puede usar AMO Security Objetcs. Con estos objetos de manera programática con código dotnet se pueden administrar los roles de SSAS. Una referencia en el siguiente link.

http://msdn2.microsoft.com/en-us/library/ms345081.aspx

Hoy un cliente me preguntó si era seguro el uso de la variable HTTP_REFERER. Me mandó su código de prueba para pedir mi opinión.

EL código es el siguiente.

<HTML>
<HEAD>
</HEAD>
<BODY>
<% if request.servervariables("HTTP_REFERER")= "http://164.77.11.29/Prueba/pp.htm" then %>
<P>Si tiene acceso</P>
<% else%>
<P>No tiene acceso</P>
<% end if%>
</BODY>
</HTML>

Es muy cómodo usar HTTP_REFERER para preguntar desde donde viene un cliente Web. Ojo que dije preguntar y no validar, porque en rigor es el cliente Web que declara desde donde viene. No es un dato confiable.

Alguien con algunas habilidades de programación puede hacer un script que cambie el valor de está variable, y el servidor Web no tiene como validar si el valor es real o no. Está es la técnica conocida como SPOOF.

Está validación puede ser usada en aplicaciones triviales pero no en aplicaciones WEB Seguras.

El siguiente script es un ejemplo de cómo engañar al servidor Web.

% telnet your.website.example.com 80
  GET / HTTP/1.1
  Host: your.website.example.com
  Referer: http://www.google.com/
  Connection: close
  (contents will be displayed here)

En conclusión no se debe confiar en las variables que entrega el cliente: campos de formularios o http headers. Incluso las cookies deben ser consideradas como información no confiable, en aplicaciones Web reales.</P