ID Uruguay - Integración con SAML - wiki - Seguridad
Wiki
ID Uruguay - Integración con SAML
Introducción
¿Qué es ID Uruguay?
Es la plataforma de autenticación implementada por AGESIC para centralizar cuentas de usuarios y facilitar el acceso web a los servicios digitales del Estado. Esto quiere decir que, una vez registrado en ID Uruguay, un usuario podrá ingresar a los servicios vinculados a la cuenta sin necesidad de nuevos registros ni contraseñas adicionales.
La integración con ID Uruguay se puede lograr a través del protocolo SAML o el protocolo OpenID Connect, en su perfil Web SSO, y sus particularidades son el objeto de la presente documentación. Este documento explica la integración con SAML.
Terminología
A continuación se definen los actores y elementos según la nomenclatura SAML y otros términos útiles.
Identity Provider (IDP): Es el proveedor de identidades, ID Uruguay, al cual se le delega la autenticación.
Service Provider (SP): Es la aplicación web/servicio de negocio que actuará como cliente delegando la autenticación al IDP. O sea, es el sistema que se quiere integrar al mismo. Ej: portal de organismo o empresa.
User ID (UID): Identificador de un usuario del sistema. El mismo será del tipo xx-yyy-zzzzzzz donde xx es el código ISO del país, yyy el código del tipo de documento (dni, psp, ci) y los z el numero de documento. Por ejemplo un usuario con cédula de identidad uruguaya 1231231-4 tendrá como identificador uy-ci-12312314. Para mas información de los tipo de usuarios que presentará el sistema acceder a ID Uruguay .
Assertion: Mensaje codificado en XML que se utiliza en el protocolo SAML para hacer pedidos y confirmaciones.
¿Cómo funciona?
El objetivo del sistema es delegar la autenticación en el IDP mediante el intercambio assertions. A los distintos mecanismos de comunicación se le conocen como bindings.
Sign On
El Sign On consiste en el pedido de autenticación del usuario por parte de un SP (aplicación) al IDP. En este sistema solo se autenticarán personas. De ser exitosa la autenticación, el IDP registra una sesión para ese usuario (en el contexto del explorador web) y comunica al SP el resultado de la autenticación. Quien podrá realizar un login local si el usuario cumple con las condiciones. En el caso ideal cuando el usuario se autentica de forma exitosa, se establece una sesión tanto en el IDP como en el SP.
Un Sign on se desarrolla en los siguientes pasos:
- (1) El usuario desea autenticarse a través de un SP (por ejemplo: portal web de un organismo), este enviará un Authentication Request Assertion al IDP, solicitando la autenticación del usuario que se encuentra utilizando el sistema. *
- El usuario entonces es redirigido al IDP (2) y (3) y éste se encarga de autenticarlo, con usuario y contraseña o con la cédula de identidad electrónica (4) y (5).
- Si la autenticación es exitosa o no, el IDP generará un Response Assertion que enviará al SP indicando el resultado de la autenticación (6) y (7).
La siguiente imagen ilustra un caso genérico de autenticación utilizando el protocolo SAML.
Cuando el usuario desea desloguearse, lo solicitara en la aplicación en que se encuentre y la misma enviará al IDP un Logout Assertion. Luego de procesarla el IDP retornara un assertion con el resultado del deslogueo.
Single Sign On (SSO)
Ademas de la delegación de la autenticación, este sistema permite la implementación de un SSO. El Single Sign On consiste en que el usuario puede ingresar a varios servicios autenticándose una sola vez. Esto funciona gracias a que el IDP es compartido entre todos los SP.
Por lo tanto si tenemos un usuario que se autenticó para ingresar a, por ejemplo, SP1 y va a ingresar a SP2, al iniciar sesión en este último quedará autenticado sin tener que volver a ingresar las credenciales. Lo que pasa por detrás es que SP2 solicita la autenticación al IDP y este, al ya tener una sesión activa, no le volverá a solicitar las credenciales.
Forzar Autenticación (Force Auth)
Si en el ejemplo del SSO, SP2 necesitase que el usuario confirme que es él volviendo a ingresar las credenciales, SP2 lo puede solicitar enviando nuevamente un Autentication Request con el atributo "ForceAuth" en el assertion. Este proceso es muy común cuando se va a acceder a funcionalidades o transacciones de alto riesgo para el SP y por lo tanto se quiere estar seguro de la vigencia del usuario que está utilizando el sistema. El usuario que se estuviera autenticando nuevamente con ForceAuth debe de ser el mismo que tiene la sesión activa, en caso contrario no podrá autenticarse. Si se desea autenticar un nuevo usuario se deberá primero realizar un Single Logout.
Single Log Out (SLO)
Así como se implementa el SSO, análogamente se implementa el Single Logout. En un escenario donde se tienen varios SP autenticados con el mismo IDP, cuando el usuario se desloguea en alguno de ellos, este puede enviar un Single Logout Assertion al IDP, y este se encargará de solicitar el deslogueo local a cada uno de los SP en los que estaba autenticado, quienes deberán obligatoriamente aceptar ese pedido y efectivizar el cierre de la sesión.
Solicitud de alta en el servicio
Para ser dado de alta en el servicio se debe de llenar un formulario para poder generar el "partnership" entre el SP y el IDP.
El formulario cuenta con 3 secciones:
Primera sección
Se requiere información sobre el SP y un contacto para eventuales notificaciones.
Segunda sección
Es donde se debe ingresar la información técnica del SP:
- Entity ID: En este campo se debe de ingresar el identificador del SP. El mismo debe de ser único. Es recomendable según el estándar que sea la URL del dominio. Por ejemplo: https://www.ejemplo.com.uy/id .
- Descripción: Lo que se ponga en este campo aparecerá en la pantalla de autenticación precedido por "Ingrese a ", por ejemplo si se pone "Servicio X" en la pantalla de autenticación aparecerá "Ingrese a Servicio X".
- Assertion Consumer Service Location: En este campo se debera introducir la URL donde se recibiran las respuestas SAML de la autenticación.
- Single Logout Location: En este campo se deberá introducir la URL donde se recibiran los pedidos SAML del IDP de deslogueo local.
Se debe de adjuntar junto al formulario el certificado (el archivo .cer) de Persona Jurídica Avanzada (emitido por El Correo o Abitab) que se utilizará para firmar los Assertions. En testing puede ser un certificado autofirmado.
Tercera sección
Se encuentran los datos necesarios para configurar o desarrollar el cliente SAML:
- Entity ID: es el identificador del IDP. Para envíar los pedidos de autenticación al IDP se pueden utilizar dos bindings como ya fue comentado, aquí se encuentran las URLs para cada binding.
- Single Logout Endpoint: es la URL a donde se deben enviar los pedidos o las respuestas de deslogueo.
- Se recibirá el certificado con el cual el IDP firma las assertions y un archivo de metadata del IDP para poder configurar con el mismo el SP si soportá dicha característica.
El formulario se puede solicitar y enviar a soporte@agesic.gub.uy con el asunto Alta ID Uruguay con SAML.
Descargar formulario ( 174Kb .doc )
Descargar certificado del IDP ( 2Kb .cer )
Descargar metadata del IDP ( 8Kb .xml )
Implementación
El protocolo utilizado para delegar la autenticación será SAML (Security Assertion Markup Language) en su versión 2.0. A continuación se da una descripción de la implementación especifica del IDP y la información que se intercambia.
Datos recibidos de los assertions
Al solicitar al IDP que el usuario se autentico el mismo nos devolverá un assertion con información del usuario (atributos), si este se autentico correctamente.
Los atributos recibidos en el assertion cuando el usuario se autenticó con la cédula de identidad electrónica serán:
- UID: Identificador del usuario del tipo uy-dni-zzzzzzz donde los z es el numero de documento de identidad.
- x509Certificate: Certificado en base64 y formato PEM incluido en la cedula electrónica.
- Nombre Completo: Nombre Completo encontrado en el certificado de la cedula.
- Pais Documento: uy
- Documento: Numero documento, igual a las zzzzzzzz del UID.
- Tipo Documento: dni
- Certificado: Este atributo siempre vendrá en true cuando la autenticación es con cédula.
En cambio, cuando la autenticación es con usuario y contraseña:
- UID: Identificador del usuario del tipo xx-yyy-zzzzzzz donde xx es el código ISO del país, yyy el codigo del tipo de documento (dni, psp, ci) y los z el numero de documento.
- Certificado: Este campo ira en true si el usuario asocio la firma electrónica avanzada a su usuario. Dando garantias de que es quien dice ser. En caso contrario se encontrará en false .
- Presencial: Este campo irá en true si el usuario se registro y presento la cédula de identidad presencialmente.
- Primer Nombre: Primer Nombre del usuario autenticado.
- Segundo Nombre (opcional): Segundo Nombre del usuario autenticado.
- Primer Apellido: Primer Apellido del usuario autenticado.
- Segundo Apellido: Segundo Apellido del usuario autenticado.
- Pais Documento: El mismo xx del UID
- Documento: Los mismos z que el UID
- Tipo Documento: Codigo definido por la UNAOID para el tipo de documento. En el caso de la cedula de identidad uruguaya será: 68909 .
Ejemplo del conjunto de atributos que recibirá el SP cuando la autenticación es con Cédula de Identidad Electrónica:
<saml2:AttributeStatement> <saml2:Attribute FriendlyName="Certificado" Name="Certificado" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">true</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="X509 Certificate" Name="X509Certificate" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string"> MIIFYTCCA0mgAwIBAgIQI4v+eauXgN9VXJVyswPMEjANBgkqhkiG9w0BAQsFADBtMTwwOgYDVQQD EzNBdXRvcmlkYWQgQ2VydGlmaWNhZG9yYSBkZWwgTWluaXN0ZXJpbyBkZWwgSW50ZXJpb3IxIDAe BgNVBAoTF01pbmlzdGVyaW8gZGVsIEludGVyaW9yMQswCQYDVQQGEwJVWTAeFw0xNTA1MjAxNDA4 NTBaFw0yMDA1MjAxNDA4NTBaMEMxCzAJBgNVBAYTAlVZMRQwEgYDVQQFEwtETkk0MjUwMjY0ODEe MBwGA1UEAwwVTklDT0xBUyBQSVFVRVJFWiBSQU1BMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0pJkfT6ZMQ8k373+4vB13nZ8NXX4oVizNH03kH3YhUN0RedRG2F//l6AOiltyjbY+T/7 jkte2Z2pAXzxTzd5erqSeqg5C/T4Ynq1mkHBMOAYCiw4oRQ6qJaPBKQEZ+32IH3J2H6lgtW2IIS6 ES7A7dOFE/wkCnE65OryesVqXng2DixSGxCWE/1KG0RFqOAxzgBicW6MZbZMqfX0XlON9pG4XYep P4rqp0xHRucFl7Z7Zc3Yz9gSERea8BjGD6k7cxKMaPbPhQsTfABahX1xS0epzsz/GrcZ5LYWQXVi XTSQ7ohv/u167y5a1gQJq1qaJ1afyqqKMx17F+bux0LY1wIDAQABo4IBJTCCASEwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ3uj603gPiyIbNyWQVs97HT2PM1TAfBgNVHSMEGDAWgBSfszQ8mzqpYBDKyFkEbe2tYixI/zBq BgNVHSAEYzBhMF8GC2CGWoTirh2EiAUCMFAwTgYIKwYBBQUHAgEWQnd3dy51Y2UuZ3ViLnV5L2lu Zm9ybWFjaW9uLXRlY25pY2EvcG9saXRpY2FzL2NwX3BlcnNvbmFfZmlzaWNhLnBkZjA5BgNVHR8E MjAwMC6gLKAqhihodHRwczovL2NhLm1pbnRlcmlvci5ndWIudXkvY3Jscy9jcmwuY3JsMA0GCSqG SIb3DQEBCwUAA4ICAQB5gBDFHuvgNkAEIhdYxUAYDTvwRf6alnVn6ALccPerA7a2Q4cZQSZn2RZt yfH+0c01OMuDSonDXEPzIFmpYGy9lVZcIk7j/+NNQCr+5MBaAzcgUGgHgT+xGkSxbGqGcg//x2dl U3liX8MiL49/PA4mqmZaL5RZnPt0nH5oqRrrIJTtZTQBISCR+B6Ap/QF1bOCSEFd3rIpbxC3Fv+L XXmYU6S9RSglBrihth+HPpZ9zWyKlUepLJt78BoAkSJLH+E56rbyqbkC1zk2pw1GHJntyBu0j7DD di69K4+Gulh1PBqfvEdbSPpDi6JuQSZZKG1lyhOLFm1Bm8szl6Rmxji64uf4sjZrK2JIrE4BaV9Z dvbdB10D/R3qCMg1I2scjCbogCwN+0e6dJO6BOWIEUc07YX6YH75JBQmOKdh9D7FzJM4flDezxYg wmxDogaifqx/2N4kTfZ0L1I5mN6L3Iqme7W6hlriCQei8tp43v13/6yltZLWk8V4xvlND6JGwEwC BnFLXMZk9c6TI3lhPXYSoZT2e6nenc3Cx8zZyyOZkIRHvCQolRebr7VZJ/4ZHuouUYatcri9w24m QNi9nVCzDCsC6DuuRk6fT363XLPnS4/FHQVLHk81QC8Ak2DJXtoICO6wU8jeiPxmdzbWU8xXcebb c4WbE1qAgglHkYyoaQ==</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="UID" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">uy-dni-12312314</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Nombre Completo" Name="NombreCompleto" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">rodrigo perez suarez</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Pais Documento" Name="PaisDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">uy</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Tipo Documento" Name="TipoDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">dni</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Documento" Name="Documento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">12312314</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement>
Ejemplo de conjunto de atributos cuando la autenticación fue con usuario y password:
<saml2:AttributeStatement> <saml2:Attribute FriendlyName="Certificado" Name="Certificado" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">false</saml2:AttributeValue></saml2:Attribute> <saml2:Attribute FriendlyName="Segundo Appelido" Name="SegundoApellido" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Suarez</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="UID" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">uy-ci-12312314</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Primer Nombre" Name="PrimerNombre" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Rodrigo</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Pais Documento" Name="PaisDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">uy</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Primer Appelido" Name="PrimerApellido" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Perez</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Tipo Documento" Name="TipoDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">68909</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Documento" Name="Documento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">12312314</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Presencial" Name="Presencial" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">false</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement>
Niveles de confianza de los usuarios autenticados
Habrá 4 tipos de niveles de confianza en los usuarios autenticados según como haya sido la autenticación o el registro.
- Usuarios autenticados con cédula de identidad electrónica: Son los usuarios que al momento de realizar la autenticación usaron la cédula electrónica ingrsando su PIN. Tiene el nivel de confianza máximo que el sistema puede dar, ya que se autenticaron con algo que poseen (cédula) mas algo que saben (PIN). Para identificar un usuario de este tipo debemos chequear el contexto de autenticación en el response assertion y que coincida con <saml2:AuthnContext<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI </saml2:AuthnContextClassRef></saml2:AuthnContext>.
Adicionalmente el identificador será del tipo uy-dni-zzzzzzzz . - Usuarios autenticados con usuario y password que firmaron contrato con firma electrónica avanzada: Son los usuarios que se auto-registraron o se registraron presencialmente y firmaron un acuerdo con su firma electrónica avanzada. Se chequea que la firma corresponda con el documento del UID por lo que poseen un alto nivel de confianza. Para identificar un usuario de este tipo debemos chequear el contexto de autenticación en el response assertion y que coincida con<saml2:AuthnContext><saml2:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml2:AuthnContextClassRef></saml2:AuthnContext> y el atributo Certificado en true.
- Usuarios autenticados con usuario y password y registrados presencialmente: Usuarios que se registraron en una ventanilla para tal fin y presentaron documentación (documento de identidad nacional o pasaporte). Posee un nivel de confianza alto ya que la información fue corroborada y chequeada por un operador de la plataforma.Para identificar un usuario de este tipo debemos chequear el contexto de autenticación en el response assertion y que coincida con <saml2:AuthnContext><saml2:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml2:AuthnContextClassRef></saml2:AuthnContext> y el atributo Presencial en true.
- Usuario auto-registrado: Usuario que se registro el mismo en la consola de autogestión. No tiene garantías de que es quien dice ser ya que no se presenta prueba de que el usuario es poseedor del documento de identidad ingresado. Puede servir para casos donde no se necesita tener garantías sobre la identidad o donde luego se verificará la misma (por ejemplo consulta de información pública o un sistema de agenda). Para identificar un usuario de este tipo debemos chequear el contexto de autenticación en el response assertion y que coincida con <saml2:AuthnContext><saml2:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml2:AuthnContextClassRef></saml2:AuthnContext> y con ambos atributos Certificado y Presencial en false.
Perfil y Bindings
ID Uruguay utiliza el perfil "Web SSO" de SAML 2.0, que está pensado para usarse en navegadores web. Cuando el usuario desea autenticarse en un servicio, el mismo generará un assertion SAML y redirigirá al usuario al IDP junto con el assertion. La respuesta del IDP se realizará de igual forma, con redirecciones del explorador.
Para este perfil existen dos bindings para enviar los mensajes; HTTP-POST y HTTP-Redirect.
El binding HTTP-POST consiste en poner el assertion en un campo de un POST http dirigido hacia la contraparte.
En el binding HTTP-Redirect se envía el mensaje a la contraparte como parámetro en la URL de un Redirect (302).
La otra gran diferencia entre estos dos bindings es que en el caso de HTTP-POST la firma del assertion se realiza dentro del xml del assertion, con firma estandar xml. En cambio en HTTP-Redirect, se codifica el assertion sin firma en un base 64. El assertion se incluye en el parametro SAMLRequest, luego en el parametro SigAlg irá el algoritmo de firma y finalmente en el parametro Signature ira la firma de los ultimos dos parametros concatenados. Luego se realizara un URL encoding para poder enviarlos como parametros en la URL.
La realización de la firma de esa manera en el binding HTTP-Redirect es debido a que queda mas liviana (de tamaño), y la principal limitación de este binding esta en el tamaño maximo de caracteres que se pueden colocar en una URL de un pedido http. Es por esto que se recomienda el binding HTTP-POST.
La limitación del binding HTTP-POST es que algunos firewalls podrían bloquear los pedidos de este tipo, pero en la actualidad esto es muy inprobable.
Si bien el uso de un binding u otro no siempre es posible debido a restricciones como el uso de HTTPS y el tamaño de las assertions, estos son independientes del comportamiento del protoclo SAML, estableciendo únicamente la forma en que se intercambian los mensajes entre SP e IDP, y no afectando en nada el comportamiento de los flujos de autenticación o de las sesiones.
Debido a que la comunicación se realiza con redirecciones del explorador, no se necesita establecer nunca una comunicación directa entre el SP y el IDP.
Contenido de los Assertions
Los assertions son mensajes xml. Se usarán 4 tipos de assertions: Authentication Request, Response, Logout Request y Logout Response assertion.
Authentication Request Assertion
Este assertion se enviará desde el SP al IDP para solicitar una autenticación.
A continuación se da un ejemplo ilustrativo del assertion para luego ser explicado. En este caso se uso el HTTP-POST binding, por eso la firma esta incluida en el xml en el nodo Signature. En el caso del binding HTTP-Redirect la firma no sería incluida en el xml (si como parámetro como fue explicado).
<?xml version="1.0" encoding="UTF-8"?> <saml2p:AuthnRequest AssertionConsumerServiceURL="https://eid-sp.portal.gub.uy/v1.1/sp-idp/saml/acs" AttributeConsumingServiceIndex="0" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained" Destination="https://eid.portal.gub.uy/v1.1/idp/profile/SAML2/POST/SSO" ForceAuthn="false" ID="_d06b8cde-3bea-43d2-be35-ce2e6ff7f3f4" IssueInstant="2016-02-04T16:24:51.496Z" ProviderName="http://sp1.ejemplo.com/" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://sp1.ejemplo.com/</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#d06b8cde-3bea-43d2-be35-ce2e6ff7f3f4"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>7JryUO+7m+3HdPwFq06q8UCg6PE=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>X4CUZFzK5US/NEDzBihn399PVKC7JGcYJgpI3v2sUcM5Yhha1qVOg780Pq SYtQM2WgJZH5/HiMtwtICyg+wN10+o4W0SxIPmgLbRON4lGEkhvVXKnclxh3kWDgRNs8CnblsAdXO DClyhaUjSU0NLGQnNrU3D8HNcHbd28M2DYeQFz1wQF+/C0C6thc3057JvA1Q/HBj0Vbz1+xpIfQbg qRXUUlm4cMfDYecY2JbgrgowSuqqUTpYaWNksqKNz/20PW8LAn5lffD6NUcQl9MN28MI5ucqL2MX8 zABWoGNuMKfHRjc6kxpoJYrqMcKCs3dNwKESxZDsdiTaG4jyOoFKA==</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDZTCCAk2gAwIBAgIBAjANBgkqhkiG9w0BAQsFADBTMQswCQYDVQQGEwJGUjEQMA4GA1UECgwH R2VtYWx0bzEMMAoGA1UECwwDSUNTMSQwIgYDVQQDDBtSJkQgRGV2IFNlcnZpY2UgUHJvdmlkZXIg Q0EwHhcNMTQwMzE3MDkxOTM5WhcNMjQwMzE0MDkxOTM5WjBKMQswCQYDVQQGEwJGUjEQMA4GA1UE CgwHR2VtYWx0bzEMMAoGA1UECwwDSUNTMRswGQYDVQQDDBJTZXJ2aWNlIFByb3ZpZGVyIDEwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDhMiozJ+EMp+4FG+eUP/l7zsgKOt3fTBLcxaf/ 07u2OI+ahxlaPHret67RZPH9ll8JTbO6Moo8KTN1D5hL2zFyU3vcvjZTpKQskztvzvS7ER4zJypM sgOD3bHc7QsJ3JxOyMwPRmaYn6dYOB754e5eb0Gp9l3gQVhX6kVKk4GlqYXYfqzdQOiaTXaqobic 0HgFHwa8RLJ6vHyK+jqCi4K04HwYoJr6MdX5UISjKaNCYpOspYsPRYLFy4IEwr3x81Dev/KZnTsA 8pBx7nYdzxcLvwnNid6UUWeggBvtt2qUaVjEeEjTsqR0kl/jSyZhPcP4PElmd4piCJUBRpGxxe0N AgMBAAGjTTBLMAkGA1UdEwQCMAAwHQYDVR0OBBYEFMLzZR7uSN43ZyGJwcBaFE1V65jxMB8GA1Ud IwQYMBaAFDnhHg0/Y0mVNnCnPHTKTv+dS8J4MA0GCSqGSIb3DQEBCwUAA4IBAQB7CZ9A/8LvkwOv ZMxiLoRzT1Uf5tRD6dx6e+ttfkgfvpXjF8xEwfcIBTAd3uawS8hSCTR72YhHE8BTfQGsZJ5kv9Ka 8qHMCxO+MAeRRqEtxZVoFtBVYw9ppolKS/YAD/VFFyiEgCMdGn3hFAkcjSETTNNjpXhQPrGYlvBl 8dVDuI8mMZy0YX0gTn+jODS5QQZx8602GWr1O4OEnXEDU4t6msx0lItTtGv9d78dmINcaya7CV6S kls/N7aboeBKiNwj11ZAvbXbMjuML8YYqmXyHyo1yGf6xd/Vz8mWRo6fUHC+kNnyL4X/zndBueV9 lE4CW3nmVZZuUD07qjN8x7Zb</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2:Conditions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:AudienceRestriction><saml2:Audience>http://sp1.ejemplo.com/</saml2:Audience></saml2:AudienceRestriction> </saml2:Conditions> <saml2p:RequestedAuthnContext> <saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"/> </saml2p:RequestedAuthnContext> </saml2p:AuthnRequest>
El nodo padre será saml2p:AuthnRequest y tendra como atributos:
- AssertionConsumerServiceURL (ACS URL): Esta URL será donde se recibirá el Authentication Response Assertion indicando el resultado de la autenticación. Debe coincidir con el ingresado en el formulario de alta, registrado previamente en el IDP. No se soporta la modificación dinámica del ACS URL.
- Destination: URL a la que se enviará el Authentication Request. Se debe seleccionar la adecuada según se use el binding POST o Redirect. Por ejemplo para el binding POST se usará https://eid.portal.gub.uy/idp/profile/SAML2/POST/SSO.
- ForceAuthn: Forzar autenticación. Si se pone false, el usuario no deberá volver a ingresar las credenciales si ya se había autenticado, por ejemplo a través de otro SP que también delegó la autenticación en este sistema. Si se pone en true el usuario debe volver a ingresar las credenciales por más que ya lo hubiese hecho y su sesión estuviese vigente. Esto se usa cuando se desea forzar que el usuario se autentique efectivamente al momento de solicitar la autenticación.
- ID: Numero aleatorio identificando la transacción. Se recomienda el uso de un numero aleatorio cuyo primer caracter sea '_' , esto porque el identificador debe ser de tipo "NCName". Debe coincidir con el que se encontrá en el Response Assertion.
- Issue Instant: Timestamp de emisión del assertion.
- Provider Name: Entity ID del SP. Debe coincidir con el ingresado en el formulario de alta y previamente registrado en el IDP.
- Version: 2.0 .
Luego los hijos del nodo raiz serán 4, Issuer, Signature, Conditions y RequestedAuthContext.
- El nodo Issuer deberá contener el Entiy ID del SP al igual que en el atributo Provider Name del nodo Raíz.
- El nodo Signature se usa en el caso del binding POST y contendrá la firma del XML estándar realizada con el certificado del SP con que se dio de alta. Los métodos de digest, canonicalización y transformación son los especificados en el ejemplo. Se debe incluir el certificado de la Persona Jurídica firmante del Assertion en el campo <ds:x509Certificate> .
Próximamente se cambiará el agoritmo de hashing a SHA-256
- En Conditions se puede indicar a quién va dirigida la respuesta, la que deberá coincidir con el Entity ID del SP.
- En RequestedAuthnContext, se puede indicar cómo se desea que sea la autenticación. El mismo tiene un hijo "AuthnContextClassRef", que al dejarlo vacio se indica que cualquier metodo es valido (documento de identidad o password), si se desea que la autenticación sea con usuario y contraseña se debe poner urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport , si se desea que sea con cédula debe incluir urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI .
Authentication Response Assertion
Este es el mensaje que envía el IDP al SP para expresar que se realizó una autenticación exitosa, o que el usuario ya estaba autenticado en el IDP.
A continuación un ejemplo ilustrativo del authentication response assertion:
<?xml version="1.0" encoding="UTF-8"?> <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://test-eid.pge.red.uy/v1.1/sp-idp/saml/acs" ID="_9124f5ed7d644263c042edc32e30de1a" InResponseTo="_d06b8cde-3bea-43d2-be35-ce2e6ff7f3f4" IssueInstant="2016-08-19T19:55:39.865Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://test-eid.portal.gub.uy/idp</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_9124f5ed7d644263c042edc32e30de1a"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>PyaSdwfEkVEqbVS1/O6qYXuHlU4=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>crACRqSPMCPuJxsBtuY2FCe/qGNucM4AdpxV+awYAEa+uSzF yLsjDFTZmzvbxFTYr+bxFQM1T0zzz5somJNmdt95NGhGMaD9rUHJf/3ARuSdfsb6BBy 0yL8gTnIO7H7VaSYmQrYcVdbL3P3hE6A0kO7LzVDMVgjVk78sgTP+rfuOrXwA6FPmVH 8YxC3q0z9hl2Vd2rmLe9bB+g3XQXPOzP8Xge8XYfDuZQHZWZ6OW0i30TNHGaZJVMLik FzIc7oQ4opHP0G0GyQu0hz5rYsndjW4c1RP4y9QEuvbEBQcdq8imECEtjP0QIeNpQQa UuSwuXhOKlhX4V5tD4o1OaSkw==</ds:SignatureValue> <ds:KeyInfo><ds:X509Data><ds:X509Certificate> MIIGkDCCBHigAwIBAgIUAS/jVUldwEKKjbmRAZS36pQT3MkwDQYJKoZIhvcNAQEL<br>BQAwWjEdMBsGA1UEAxMUQ29ycmVvIFVydWd1YXlvIC0gQ0ExLDAqBgNVBAoMI0Fk<br>bWluaXN0cmFjacOzbiBOYWNpb25hbCBkZSBDb3JyZW9zMQswCQYDVQQGEwJVWTAe<br>Fw0xNzAyMTQyMzQxNDVaFw0xOTAyMTQyMzQxNDVaMIG7MRgwFgYDVQQFEw9SVUMy<br>MTU5OTYwNjAwMTUxCzAJBgNVBAYTAlVZMXoweAYDVQQKE3FBR0VOQ0lBIFBBUkEg<br>RUwgREVTQVJST0xMTyBERUwgR09CSUVSTk8gREUgR0VTVElPTiBFTEVDVFJPTklD<br>QSBZIExBIFNPQ0lFREFEIERFIExBIElORk9STUFDSU9OIFkgREVMIENPTk9DSU1J<br>RU5UTzEWMBQGA1UEAxMNQUdFU0lDLUNPRVNZUzCCASIwDQYJKoZIhvcNAQEBBQAD<br>ggEPADCCAQoCggEBAKIUwqjjY+6mIAhiv91QENU+jrd1ZMteH7H4qQ/vBeDEPndE<br>iAyOK5vSb6gFt6q1i4IF2O1lo5MO1fjjay5187ZwA67X5g1AuSCSLmlm1+Xo4pqY<br>EQCx/CJuBiPcgdRJVh920XZMVA2FIS2scNqNN8a3BozsMLaXiXA8YXzG7HFrAB+F<br>LvHaZ55SlyIOZbOA5RAg2v8IqkQJAiwYR6waxH0Hk5UkYvwkeCmBdn5w+ez6iuKD<br>m+nRnNXge13Tl4ap3/M3DjdWwbWCKwyd2P3IYr8WH7VVA9UsA8qVLP4qF5/bW5GS<br>f9AGcOVetiAJYWCgFglohJiFe7cb3xvuCDDlmYUCAwEAAaOCAeowggHmMHkGCCsG<br>AQUFBwEBBG0wazA2BggrBgEFBQcwAoYqaHR0cDovL2FuY2NhLmNvcnJlby5jb20u<br>dXkvYW5jY2EvYW5jY2EuY2VyMDEGCCsGAQUFBzABhiVodHRwOi8vYW5jY2EuY29y<br>cmVvLmNvbS51eS9hbmNjYS9PQ1NQMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMBAf8E<br>AjAAMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9hbmNjYS5jb3JyZW8uY29tLnV5<br>L2FuY2NhL2FuY2NhLmNybDCBuAYDVR0gBIGwMIGtMGQGC2CGWoTirh2EiAUEMFUw<br>UwYIKwYBBQUHAgEWR2h0dHA6Ly91Y2UuZ3ViLnV5L2luZm9ybWFjaW9uLXRlY25p<br>Y2EvcG9saXRpY2FzL2NwX3BlcnNvbmFfanVyaWRpY2EucGRmMEUGC2CGWoTirh2E<br>iAUGMDYwNAYIKwYBBQUHAgEWKGh0dHA6Ly9hbmNjYS5jb3JyZW8uY29tLnV5L2Fu<br>Y2NhL2Nwcy5wZGYwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0OBBYEFJtsykP7<br>u2AG5nyUsCl0GWdwyxNxMB8GA1UdIwQYMBaAFGzisCaNW9YmCB+YXWngDn9V7K52<br>MA0GCSqGSIb3DQEBCwUAA4ICAQBHE52eZe6czHJ2InJaUpZRHpmyXNqEtsseso1G<br>JsGl7nffF02kq0ueWPLunLlyHoujdMgUgyBkH4eXE248zmQ0VSWkykGvJVhfKSLf<br>8DsxkwR6axpqmeKrufbx4Jzf/bKIK6TYBrFSCEQJ93iSk0MW4K3QL3sqKM087KsG<br>miuGeC760gT76v7cdkwwCc6XO6hMYlcpUm+bOcB9DgKgntugC526rK69r8pMRo8s<br>fL3kpk0g4ShjXYJH88eLgmDvew7ZjECT1uAD9dUeTpAtGux0RMay7VCZE2BV/jZt<br>uZMw/Ag7AgnKdXcSbA0tJqumeMPyDxs5BPVKrsznSjiXYZlDf8i3JEEmdDVD5Otd<br>WVcEDTrE/3yi8Gy5nF+kTR8qgcGc6CZKTtZFzCUrAcdEAuBuVm61SbAH6X9qlJ0c<br>giyqBokRhu6/prjPqKr5dFV7qUkcpgQZAiKzPkHCkegNEoav/86jboaPl4xos3ve<br>x8bZW1IA5KB3GNvMIdXi4xrb2p2AGgbL4E9WsXUnMGoErQXIRWtvHolcq/M+L2l5<br>z+AiwYdBe5t6xgXuHtDsirYYspPgFwXJ5zNhX/nukHhJXmbALi8QDITq7j2D+APD<br>0yeKUb/Yurs4Szy11oZAJMWDXAtZUQJN2nqsozMdYJJx0+c+jUgkpL0zKTIFytvX<br>yP7BHg== </ds:X509Certificate></ds:X509Data></ds:KeyInfo> </ds:Signature> <saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_89a21c16e2fbc949e0dc59b35e4b9356" IssueInstant="2016-08-19T19:55:39.865Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://test-eid.portal.gub.uy/idp</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_89a21c16e2fbc949e0dc59b35e4b9356"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>tF3/GucTBtzvUMM1nWId2G76Jwk=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>C4zTEWkxISwbcArkyvMU+axdPOXYQwlyJQd3NIDoDFqEjy3SK7lUEGuuQ 3UMT7OQ+B+/wY7AVcISYljgD9l9McJChTUFnWv3uQq4L5XSstK+gTrH/L7THru6GJEL0GCvoihs4 k4cmi2Aztpxtv8kO6Tv0C/z71iWiNmZ8FtGN1gP0/Df3Af9gyTStJD/hObQu92DLQQFwTbdqCpIz VGXyuzhpNiyD6ibO03neBcsOkPCw8hbAWfR7dCVUN9EOvh2ojxwHIbQeJGZmgfjatPaqvNANJX7J bI2/Mkef+OcwstOiRgJqy6R2k6EsaS4LhCHnOBNoX31+UJr5psibE0kwQ== </ds:SignatureValue> <ds:KeyInfo><ds:X509Data><ds:X509Certificate> MIIGkDCCBHigAwIBAgIUAS/jVUldwEKKjbmRAZS36pQT3MkwDQYJKoZIhvcNAQEL<br>BQAwWjEdMBsGA1UEAxMUQ29ycmVvIFVydWd1YXlvIC0gQ0ExLDAqBgNVBAoMI0Fk<br>bWluaXN0cmFjacOzbiBOYWNpb25hbCBkZSBDb3JyZW9zMQswCQYDVQQGEwJVWTAe<br>Fw0xNzAyMTQyMzQxNDVaFw0xOTAyMTQyMzQxNDVaMIG7MRgwFgYDVQQFEw9SVUMy<br>MTU5OTYwNjAwMTUxCzAJBgNVBAYTAlVZMXoweAYDVQQKE3FBR0VOQ0lBIFBBUkEg<br>RUwgREVTQVJST0xMTyBERUwgR09CSUVSTk8gREUgR0VTVElPTiBFTEVDVFJPTklD<br>QSBZIExBIFNPQ0lFREFEIERFIExBIElORk9STUFDSU9OIFkgREVMIENPTk9DSU1J<br>RU5UTzEWMBQGA1UEAxMNQUdFU0lDLUNPRVNZUzCCASIwDQYJKoZIhvcNAQEBBQAD<br>ggEPADCCAQoCggEBAKIUwqjjY+6mIAhiv91QENU+jrd1ZMteH7H4qQ/vBeDEPndE<br>iAyOK5vSb6gFt6q1i4IF2O1lo5MO1fjjay5187ZwA67X5g1AuSCSLmlm1+Xo4pqY<br>EQCx/CJuBiPcgdRJVh920XZMVA2FIS2scNqNN8a3BozsMLaXiXA8YXzG7HFrAB+F<br>LvHaZ55SlyIOZbOA5RAg2v8IqkQJAiwYR6waxH0Hk5UkYvwkeCmBdn5w+ez6iuKD<br>m+nRnNXge13Tl4ap3/M3DjdWwbWCKwyd2P3IYr8WH7VVA9UsA8qVLP4qF5/bW5GS<br>f9AGcOVetiAJYWCgFglohJiFe7cb3xvuCDDlmYUCAwEAAaOCAeowggHmMHkGCCsG<br>AQUFBwEBBG0wazA2BggrBgEFBQcwAoYqaHR0cDovL2FuY2NhLmNvcnJlby5jb20u<br>dXkvYW5jY2EvYW5jY2EuY2VyMDEGCCsGAQUFBzABhiVodHRwOi8vYW5jY2EuY29y<br>cmVvLmNvbS51eS9hbmNjYS9PQ1NQMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMBAf8E<br>AjAAMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9hbmNjYS5jb3JyZW8uY29tLnV5<br>L2FuY2NhL2FuY2NhLmNybDCBuAYDVR0gBIGwMIGtMGQGC2CGWoTirh2EiAUEMFUw<br>UwYIKwYBBQUHAgEWR2h0dHA6Ly91Y2UuZ3ViLnV5L2luZm9ybWFjaW9uLXRlY25p<br>Y2EvcG9saXRpY2FzL2NwX3BlcnNvbmFfanVyaWRpY2EucGRmMEUGC2CGWoTirh2E<br>iAUGMDYwNAYIKwYBBQUHAgEWKGh0dHA6Ly9hbmNjYS5jb3JyZW8uY29tLnV5L2Fu<br>Y2NhL2Nwcy5wZGYwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0OBBYEFJtsykP7<br>u2AG5nyUsCl0GWdwyxNxMB8GA1UdIwQYMBaAFGzisCaNW9YmCB+YXWngDn9V7K52<br>MA0GCSqGSIb3DQEBCwUAA4ICAQBHE52eZe6czHJ2InJaUpZRHpmyXNqEtsseso1G<br>JsGl7nffF02kq0ueWPLunLlyHoujdMgUgyBkH4eXE248zmQ0VSWkykGvJVhfKSLf<br>8DsxkwR6axpqmeKrufbx4Jzf/bKIK6TYBrFSCEQJ93iSk0MW4K3QL3sqKM087KsG<br>miuGeC760gT76v7cdkwwCc6XO6hMYlcpUm+bOcB9DgKgntugC526rK69r8pMRo8s<br>fL3kpk0g4ShjXYJH88eLgmDvew7ZjECT1uAD9dUeTpAtGux0RMay7VCZE2BV/jZt<br>uZMw/Ag7AgnKdXcSbA0tJqumeMPyDxs5BPVKrsznSjiXYZlDf8i3JEEmdDVD5Otd<br>WVcEDTrE/3yi8Gy5nF+kTR8qgcGc6CZKTtZFzCUrAcdEAuBuVm61SbAH6X9qlJ0c<br>giyqBokRhu6/prjPqKr5dFV7qUkcpgQZAiKzPkHCkegNEoav/86jboaPl4xos3ve<br>x8bZW1IA5KB3GNvMIdXi4xrb2p2AGgbL4E9WsXUnMGoErQXIRWtvHolcq/M+L2l5<br>z+AiwYdBe5t6xgXuHtDsirYYspPgFwXJ5zNhX/nukHhJXmbALi8QDITq7j2D+APD<br>0yeKUb/Yurs4Szy11oZAJMWDXAtZUQJN2nqsozMdYJJx0+c+jUgkpL0zKTIFytvX<br>yP7BHg== </ds:X509Certificate></ds:X509Data></ds:KeyInfo> </ds:Signature> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://test-eid.portal.gub.uy/idp">_825e118486db99f3106a5bc0829f732a</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData Address="10.255.15.54" InResponseTo="_d06b8cde-3bea-43d2-be35-ce2e6ff7f3f4" NotOnOrAfter="2016-08-19T20:00:39.865Z" Recipient="https://test-eid.pge.red.uy/v1.1/sp-idp/saml/acs"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2016-08-19T19:55:39.865Z" NotOnOrAfter="2016-08-19T20:00:39.865Z"> <saml2:AudienceRestriction><saml2:Audience>http://sp1.ejemplo.com/</saml2:Audience></saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2016-08-19T19:55:39.662Z" SessionIndex="5f784076c0c17264942d28ce9a7b8d9ad8891ee9b0527f07b7db4f1e7f6044d0"> <saml2:SubjectLocality Address="10.255.15.54"/> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute FriendlyName="Certificado" Name="Certificado" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">false</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="UID" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">UY-ci-12312314</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Primer Nombre" Name="PrimerNombre" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Rodrigo</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Pais Documento" Name="PaisDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">UY</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Primer Appelido" Name="PrimerApellido" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Perez</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Tipo Documento" Name="TipoDocumento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">68909</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Documento" Name="Documento" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">12312314</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="Presencial" Name="Presencial" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">false</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion> </saml2p:Response>
El Authentication Response Assertion es el mensaje que envia el IDP al SP en respuesta a un pedido de autenticación. El mismo indica si el usuario se autenticó con exito o no, y en caso afirmativo, indica los datos del mismo.
Se forma con un nodo padre saml2p:Response con los siguientes atributos:
Destination: contiene la URL hacia donde es dirigido este assertion.
ID: un identificador del assertion. Se recomienda el uso de un numero aleatorio cuyo primer caracter sea '_' , esto porque el identificador debe ser de tipo "NCName".
InResponseTo: ID del Authentication Request Assertion al que se esta respondiendo.
IssueInstant: fecha de emisión del Assertion.
Version: 2.0 .
El nodo raíz está compuesto por los nodos:
Issuer con el Entity ID del IDP (https://eid.portal.gub.uy/idp)
Signature con la firma xml de todo el Response.
Status con el resultado de la autenticación, si fue exitosa o no.
En caso de ser exitosa <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
En caso contrario <saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/> </saml2p:StatusCode></saml2p:Status> .
Assertion con los atributos del sujeto autenticado.
En el nodo Assertion es donde tendremos la información sobre la autenticación. Tiene como atributos:
- un ID, la fecha de emisión y la versión de forma análoga al nodo raíz.
- También de forma análoga al nodo raíz tiene la firma (Signature) con alcance restringido al nodo Assertion.
En el nodo Subject se indica el ID del sujeto dependiendo el formato elejido en el formulario podrá ser urn:oasis:names:tc:SAML:2.0:nameid-format:transient o urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . Con transient se devuelve un identificador temporal, mientras que con unspecified se devuelve el UID en el formato real PP-TD-NNNNNNNN (País-Tipo-Número de documento). El NameID debe de ser guardado por lo menos en la sesión para poder solicitar un deslogueo global. De todas maneras el UID es enviado como atributo en otro nodo. También se incluye información del ID del Authentication Request, hasta cuándo es válido el assertion y la URL a donde se lo está enviando. Estos últimos datos sirven para que el SP pueda cerrar el Authentication Response contra el Request originalmente realizado, tanto en tiempos de validez como contra el ID originalmente enviado.
- El nodo Conditions, indica la fecha desde que es válido el assertion y la fecha hasta la que es valida el assertion en los atributos NotBefore y NotOnOrAfter respectivamente. En Audience se indica el Entity ID del SP al que va dirigido el assertion, y cualquier identificador diferente al propio debería ser descartado.
AuthnStatement tiene como atributo el SessionIndex , que representa el ID de la sesión. Es importante guardar este identificador ya que será el que usaremos para solicitar el deslogueo global. Otro atributo es la fecha de emisión del assertion. En Subject Locality irá la IP desde donde es enviado el assertion (el IDP). Dentro del AuthnStatement irán varios nodos, particularmente importante es AuthnContext, ya que contiene el método por el cual se autenticó el usuario. Sus valores posibles son los mismos que se podían utilizar para pedir un método particular en el Authentication Response, es decir: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport si se hizo login con usuario y password, y urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI si se hizo login con CI electrónica.
Logout Request
El Logout Request Assertion es utilizado en dos momentos. Cuando un SP solicita al IDP el deslogueo global. Y cuando el IDP debe solicitar al resto de los SP (los que no hicieron el request anterior) que realicen el deslogueo local.
El Logout Request se envía con el binding Redirect, por lo que el assertion se pone en un paramerto SAMLRequest, y se complementa con los parametros SigAlg donde ira el algoritmo de firma y el parametro Signature donde ira la firma en si.
<?xml version="1.0" encoding="UTF-8"?> <saml2p:LogoutRequest Destination="https://eid.portal.gub.uy/idp/profile/SAML2/Redirect/SLO" ID="_98eb3adc-dca5-4be7-869d-43bcaa3b0615" IssueInstant="2016-02-04T16:26:13.257Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://sp1.ejemplo.com/</saml2:Issuer> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">uy-ci-42502648</saml2:NameID> <saml2p:SessionIndex>5f784076c0c17264942d28ce9a7b8d9ad8891ee9b0527f07b7db4f1e7f6044d0</saml2p:SessionIndex> </saml2p:LogoutRequest>
El logout request assertion esta compuesto por un nodo raiz "saml2p:LogoutRequest" que tendrá como atributos:
Destination el cual contendra el endpoint del IDP donde se solicitará el deslogueo (URL), en el caso donde el SP solicita el deslogueo global; en el caso donde el IDP esta solicitando el deslogueo local, pondra en Destination el endpoint "Single Logout Location" que fue ingresado en el formulario y hacia donde se redirigirá el LogoutRequest.
ID: Numero aleatorio identificando la transacción.
Issue Instant: Timestamp de emisión del assertion.
Version: 2.0 .
El nodo raiz tendrá tres sub nodos: Issuer, NameID y SessionIndex.
- En el nodo Issuer ira el Entity ID del SP. Debe coincidir con el ingresado en el formulario de alta y previamente registrado en el IDP.
- En NameID se debera incluir el mismo identificador recibido del sujeto autenticado que vino en el nodo Subject del Authentication Response Assertion.
En el nodo SessionIndex ira el mismo identificador de sesión obtenido en el Authentication Response Assertion. En el caso de los Request enviados por el IDP (para deslogueo local) no será incluido.
Logout Response Assertion
El logout response, es enviado como respuesa a un Logout Request. Al igual que en los LogoutRequest se usará en dos casos: cuando los SP deben responderle al IDP sobre el deslogueo local exitoso, y cuando el IDP le debe avisar el resultado del mismo al SP que hizo el request de deslogueo global original.
<?xml version="1.0" encoding="UTF-8"?> <saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://eid.portal.gub.uy/sp-idp/saml/sls" ID="_4c03f43d74b4948622322e8fcbc84fc0" InResponseTo="_98eb3adc-dca5-4be7-869d-43bcaa3b0615" IssueInstant="2016-02-04T16:24:01.998Z" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp.portal.gub.uy</saml2:Issuer> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </saml2p:Status> </saml2p:LogoutResponse>
El nodo raiz de un Logout Response tendra los atributos comunes a los assertions de respuesta; Destination, ID, InResponseTo, IssueInstant y Version.
- Destination: contiene la URL hacia donde es dirigido este assertion. En el caso de que estemos respondiendo a un pedido de deslogueo local por parte del IDP será el endpoint de Logout del IDP. En caso de que sea el IDP que nos estará respondiendo a nuestro pedido de autenticación global, será la URL ingresada en el formulario Single Logout Response Location
- ID: un identificador del assertion.
- InResponseTo: ID del Logout Request al que se esta respondiendo.
- IssueInstant: fecha de emisión del Assertion.
- Version: 2.0 .
El nodo raiz tendra dos sub nodos:
Issuer: De ser el logout response del SP al IDP en este campo debera ir el Entity ID del SP. Debe coincidir con el ingresado en el formulario de alta y previamente registrado en el IDP. En caso contrario sera el Entity Id del IDP.
Status: Indicara el resultado del deslogueo. Habra dos codigos: Success en caso exitoso y PartialLogout que se envia al responderle al SP que inicio el pedido de deslogueo global bajo la condicion de que no todos los SP comunicaron el resultado del deslogueo local de forma exitosa (el SP que inicia el deslogueo global se asume que se desloguea localmente de forma exitosa).