jueves, 12 de diciembre de 2013

Resolviendo el rompecabezas: WCF TCP Federation con WIF y Windows Azure ACS - PARTE 2


En el post anterior, les contaba un poco acerca de un escenario que teníamos, en el cual debíamos asegurar las comunicaciones con un WCF con NetTcpBinding hosteado en Azure. También hablamos acerca de la tecnología utilizada para ello (Windows Azure ACS) y explicamos un poquito acerca de la misma. En este segundo post, trataré de detallar los pasos necesarios para llegar a la solución 
Pre Requisitos

 
Para poder seguir los pasos que se detallan a continuación, es necesario tener instalados los siguientes elementos:
Para comenzar con el proceso debemos crear un ACS Namespace. Para ello, debemos ingresar al panel de manejo de Windows Azure, hacer clic en Active Directory, hacer un clic en Access Control Namespaces, luego en New, Quick Create e ingresar un nombre de namespace adecuado.




Una vez que tenemos creado el Namespace, debemos configurarlo. Para ello, debemos hacer un clic en el namespace que deseamos configurar y luego hacer clic en el botón "Manage" que está en barra de comandos (parte inferior de la pantalla)


Importante: el usuario debe tener permisos de administrador de active directory, no sirven los permisos de co-administrador

 

El siguiente paso es configurar una aplicación de usuario de confianza (en inglés Relying Party Applications). En nuestro caso la aplicación en cuestión va a ser el servicio wcf. Para realizar dicha operación debemos hacer un clic en Aplicaciones de usuario de confianza y luego en Agregar.

 



Los datos que debemos ingresar en la pantalla que aparece luego de haber hecho clic en agregar son:




Nombre: Un nombre amigable, por ejemplo "Sistema Gestión Pagos"
Dominio (Realm): La URI para el cual es válido el token de seguridad que emite ACS, en nuestro caso net.tcp://localhost/MiServicioWCF.svc. Debemos tener presente que esta dirección va a depender de la dirección en donde este publicado el servicio, así que cuando tengamos el wcf publicado deberemos volver para cambiar este dato por el de producción.
Dirección URL de retorno: es la dirección URL a la que ACS devuelve el token de seguridad, en nuestro caso la dejamos vacía.

Dirección URL del error (opcional): es la dirección URL a la que ACS redirige a los usuarios si se produce un error durante el proceso de inicio de sesión, en nuestro caso la dejamos vacía.

Formato de tokens: formato del token emitido por ACS, en nuestro caso seleccionamos "SAML 2.0"
Directiva de cifrado de tokens: En nuestro caso se debe seleccionar "Requerir cifrado"
Vigencia de tokens (seg.): Dejamos la vigencia por defecto (600 seg)
Proveedor de identidad: Debemos desmarcar todos los proveedores de identidad (más adelante vamos a configurar el proveedor de utilidad que utilizaremos)
Grupo de reglas: Debemos dejar marcado "Crear nuevo grupo de reglas"
Firma de tokens: Debemos dejar marcado "Use un certificado de espacio de nombres de servicio (estándar) "
Cifrado de tokens: Debemos cargar un certificado para el cifrado de tokens.

 




Acerca de los certificados

En teoría se deberían tener 3 certificados con sus claves públicas/privadas como se detalla en el siguiente ejemplo http://msdn.microsoft.com/en-us/library/windowsazure/hh289316.aspx en la sección "What You Should Know". A efectos de practicidad, se utilizará para todos los casos el mismo certificado generado en entorno de desarrollo y que será adjuntado a este documento.

Continuará...


En la tercera parte de esta serie, les mostrare como configurar el servicio y su cliente... hasta la próxima!

No hay comentarios:

Publicar un comentario