creación)de)federación)de) iden-dad)paralas)redes) académicas) · • federaciones)de)iden-dad)...

112
Creación de Federación de Iden-dad para las Redes Académicas Camila Santos Analista em TIC – RNP Iden/ty Management Workshop (CHAINREDSELCIRA) Cancún, México Mayo/2014

Upload: others

Post on 07-Jul-2020

4 views

Category:

Documents


0 download

TRANSCRIPT

Creación  de  Federación  de  Iden-dad  para  las  Redes  Académicas      Camila  Santos    Analista  em  TIC  –  RNP    

 Iden/ty  Management  Workshop  (CHAINREDS-­‐ELCIRA)  Cancún,  México                                                                                                                      Mayo/2014  

•  Analista  en  TIC  de  RNP  (Brasil)  •  Ingeniera  informá-ca  por  la  UNICAMP  (Brasil),  especialista  en  

ingeniería  de  redes  y  sistemas  de  telecomunicaciones  •  Cer-ficada  ISO  20000  y  ITIL  v3  •  Trabaja  con  el  equipo  de  ges-ón  de  servicios  en  RNP  desde  

2009,  y  en  federaciones  de  iden-dad  desde  2010  •  Miembro  del  Comité  Técnico  de  Ges-ón  de  Iden-dad  en  

Brasil  

Camila  Santos  

•  Federaciones  de  iden-dad  •  Elementos  y  conceptos  de  una  federación  •  Cómo  funciona  una  federación  •  Definición  de  polí-cas  •  Definición  del  esquema  •  Proveedores  de  iden-dad  y  de  servicio  •  Discovery  Service  •  Cer-ficados  •  Metadatos  de  la  federación  •  Ges-ón  de  iden-dad  

Índice  

Federaciones  de  iden/dad  

•  El  problema  de  cuentas  de  usuario  versus  acceso  académico  a  servicios  

― En  ambientes  académicos  es  posible  encontrar  los  siguientes  escenarios:  ― Sistemas  que  solo  pueden  ser  u-lizados  dentro  de  la  red  

de  la  ins-tución  

― Sistemas  que  solo  pueden  ser  u-lizados  por  usuarios  específicos  

Federaciones  de  iden/dad  

•  El  problema  de  cuentas  de  usuario  versus  acceso  académico  a  servicios  

― En  ambientes  académicos  es  posible  encontrar  los  siguientes  escenarios:  ― Sistemas  que  solo  pueden  ser  u-lizados  dentro  de  la  red  

de  la  ins-tución  

― Sistemas  que  solo  pueden  ser  u-lizados  por  usuarios  específicos  

Federaciones  de  iden/dad  

Poco  cómodo  

Nuevas  cuentas  de  usuario  

•  Hay  posibilidades…  ― U/lización  de  proxy  para  acceso  remoto  a  servicios  

§  Puede  exigir  conocimiento  técnico  del  usuario  §  Mayor  trabajo  del  equipo  de  soporte  

― Una  cuenta  para  cada  servicio,  por  usuario  §  El  usuario  debe  acordarse  de  muchos  nombres  y  

contraseñas  §  El  administrador  debe  definir  diferentes  permisos  para  

cada  cuenta  de  cada  usuario  ― Cuenta  única  para  departamentos  o  para  clases  de  usuarios  

§  No  hay  como    diferenciar  los  derechos  de  un  usuario  §  No  hay  como  hacer  una  auditoria    

Federaciones  de  iden/dad  

•  …  o  se  puede  u/lizar  una  federación  •  ¿Qué  es?  ― Red  de  confianza  en  que  cada  ins/tución  es  responsable  por  

realizar  la  auten/cación  y  proveer  informaciones  sobre  sus  usuarios  hasta  servicios  autorizados  

― Sus  conceptos  están  basados  en  una  infraestructura  de  auten/cación  y  autorización,  que  permite  a  los  usuarios  que  mantengan  todos  sus  atributos  en  la  ins/tución  de  origen  y  acceder  a  los  recursos  ofrecidos  por  la  federación  

― Los  servicios  de  la  federación  deben  estar  basados  en  las  relaciones  de  confianza  definidas  por  la  RNIE  

Federaciones  de  iden/dad  

•  Beneficios  para  la  creación  de  federaciones  –  para  quién  accede  ― Acceso  a  recursos  y  servicios  restrictos  al  ambiente  

académico  de  fuera  de  la  red  de  la  ins/tución  y  sin  necesidad  de  un  proxy  

― Una  única  iden/dad  sirve  como  pasaporte  para  los  servicios  académicos  y    para  los  servicios  federados  

― Seguridad  en  el  envío  de  informaciones  y  reconocimiento  del  usuario  

― Single  Sign-­‐on  (SSO)  

Federaciones  de  iden/dad  

•  Beneficios  para  la  creación  de  federaciones  –  para  quién  provee  ― Controle  de  acceso  y  garan_a  de  iden/dad  de  los  usuarios  ― Adopción  creciente  por  ins/tuciones  en  todo  el  mundo  ― No  necesita  mantener  cuentas  de  usuario  ― Menor  cuesto  de  manutención  del  servicio  

Federaciones  de  iden/dad  

•  Federaciones  existentes  actualmente  #Austria - ACOnet#Australia - AAF#Bélgica - Belnet#Brasil - CAFe#Canadá - CAF#Suiza - SWITCHaai#Chile - COFRe#República Checa – eduID.cz#Alemania - DFN-AAI#Dinamarca - WAYF#Estonia - TAAT#España - SIR#

Finlandia - Haka#Francia - Fédération Éducation-Recherche#Grecia - GRNET#Croacia - AAI@EduHr###Hungría - eduID.hu#Irlanda - Edugate#Italia - IDEM#Japón - GakuNin#Letonia – LAIFE#Holanda - SURFfederatie#Noruega - FEIDE#Nueva Zelanda - Tuakiri New Zealand Access Federation#Portugal - RCTSaai#Suecia - SWAMID#Eslovaquia - ArnesAAI Slovenska #Reino Unido - UK Access Management Federation for Education and Research#Estados Unidos - InCommon#Internacional - IGTF#

#

30 federaciones, más 11 federaciones piloto#

Federaciones  de  iden/dad  

•  REFEDS  -­‐  Research  and  Educa/on  Federa/ons  ― Tiene  por  obje/vo  el  cambio  de  procesos,  prác/cas  y  

polí/cas  entre  federaciones  de  iden/dad,  y  también  de  favorecer  la  discusión  de  modos  de  facilitar  la  interacción  entre  federaciones    

― REFEDS  man/ene  una  lista  de    todas  las  federaciones  que  trabajan  asociadas  a  ins/tuciones  de  enseñanza  y  inves/gación  

Federaciones  de  iden/dad  

•  REFEDS  –  Mapa  de  ins/tuciones  

Federaciones  de  iden/dad  

•  REFEDS  –  Discovery  Guide  ― Una  documentación  publicada  por  REFEDS  es  el  Discovery  

Guide,  un  guía  sobre  como  presentar  la  iden/dad  federada  a  sus  usuarios,  buenas  prác/cas  en  federaciones  y  ejemplos  de  como  tener  una  buena  experiencia  de  u/lización  

hap://discovery.refeds.org/  

Federaciones  de  iden/dad  

•  REFEDS  –  Mejores  prác/cas  en  el  Discovery  Guide  

Federaciones  de  iden/dad  

Dónde  el  usuario  debe  auten/carse  

•  REFEDS  –  Mejores  prác/cas  en  el  Discovery  Guide  

Federaciones  de  iden/dad  

Cómo  presentar  auten/caciones  locales  

•  REFEDS  –  Mejores  prác/cas  en  el  Discovery  Guide  

Federaciones  de  iden/dad  

U/lización  de  un  Discovery  Service  

•  REFEDS  –  Mejores  prác/cas  en  el  Discovery  Guide  

Federaciones  de  iden/dad  

Opciones  para  los  usuarios  

•  REFEDS  –  Mejores  prác/cas  en  el  Discovery  Guide  ― Basado  en  el  modelo  definido  por  Espresso:  Establishing  

Suggested  Prac/ces  Regarding  Single  Sign-­‐On  

Federaciones  de  iden/dad  

hap://www.niso.org/workrooms/sso  

Elementos  y  conceptos  de  una  federación  

•  Iden/dad  única  

Elementos  y  conceptos  de  una  federación  

Fuente:  h^p://openidexplained.com  

•  Iden/dad  única:  antes…  

Elementos  y  conceptos  de  una  federación  

Fuente:  ESR-­‐RNP  

•  Iden/dad  única:  …  y  después  

Elementos  y  conceptos  de  una  federación  

Fuente:  ESR-­‐RNP  

•  Single  Sign-­‐on  (SSO)  ― Mecanismo  que  posibilita  que  un  usuario  pueda  acceder  a  

múl/plos  servicios  con  una  única  acción  de  auten/cación  ― Mientras  el  token  de  auten/cación  sea  válido,  el  usuario  no  

tendrá  que  se  auten/car  de  nuevo  en  cualquier  servicio  de  la  federación  

― U/lización  de  las  credenciales  académicas  para  acceso  a  todos  los  servicios  de  la  federación  

― Asociación  con  la  base  de  datos  académica  a  través  de  un  LDAP  

― Definición  de  esquemas  para  uniformizar  la  comunicación  y  el  cambio  de  atributos  

Elementos  y  conceptos  de  una  federación  

•  Single  Sign-­‐on  (SSO):  herramientas  open-­‐source  más  u/lizadas  en  federaciones  académicas  

Elementos  y  conceptos  de  una  federación  

•  Proveedor  de  iden/dad  (IdP)  ― Elemento  que  realiza  la  auten/cación  del  usuario  y  fornece  

sus  atributos  al  servicio  ― Fornece  un  token  de  auten/cación  al  servicio,  conteniendo  

informaciones  del  usuario  (atributos)  ―  Integrase  con  el  sistema  de  auten/cación  ins/tucional  para  

proveer  auten/cación  y  atributos  a  un  servicio  

Elementos  y  conceptos  de  una  federación  

•  Proveedor  de  iden/dad  (IdP)  ― Elemento  que  realiza  la  auten/cación  del  usuario  y  

fornece  sus  atributos  al  servicio  

― Fornece  un  token  de  auten/cación  al  servicio,  conteniendo  informaciones  del  usuario  (atributos)  

―  Integrase  con  el  sistema  de  auten/cación  ins/tucional  para  proveer  auten/cación  y  atributos  a  un  servicio  

Elementos  y  conceptos  de  una  federación  

•  Proveedor  de  iden/dad:  ejemplos  ― Proveedor  de  una  RNIE:  RNP,  InCommon,  REUNA  ― Proveedor  de  una  universidad:  USP,  INICTEL,  PUC    ― Proveedor  de  otras  ins/tuciones  de  enseñanza  e  inves/gación:  

ministerios,  museos,  laboratorios,  centros  de  inves/gación,  …  

Elementos  y  conceptos  de  una  federación  

•  LDAP  (Lightweight  Directory  Access  Protocol)  ― Protocolo  para  gerenciamiento  de  directórios,  basado  

en  TCP/IP  ― Acceso  a  informaciones  a  través  de  busca  en  árbol  por  

los  registros  

Elementos  y  conceptos  de  una  federación  

•  Directorio  de  usuarios  en  LDAP    ― Directorio  que  man/ene  las  credenciales  de  auten/cación  y  

de  los  atributos  de  cada  usuario  ― Es  consultado  por  el  IdP  para  realizar  la  auten/cación  

Elementos  y  conceptos  de  una  federación  

•  Proveedor  de  servicios  ― Representa  un  servicio  que  puede  ser  u/lizado  por  los  

miembros  de  una  federación  ― Después  de  recibir  los  atributos  de  un  usuario,  enviado  por  

su  IdP,  puede  hacer  su  autorización  para  uso  del  servicio  ― Puede  también  restringir  el  acceso  del  usuario  a  recursos  de  

acuerdo  con  los  atributos  recibidos  

Elementos  y  conceptos  de  una  federación  

•  Proveedor  de  servicios:  ejemplos  ― Sistemas  académicos,  bibliotecas  online  de  universidades,  

repositorios  y  si/os  de  publicaciones  ― Compra  de  libros  y  sofware  con  beneficios  a  miembros  de  

ins/tuciones  ― Almacenamiento  y  cambio  de  archivos  

Elementos  y  conceptos  de  una  federación  

•  Discovery  Service  (WAYF)  ― Servicio  para  descubierta  de  la  ins/tución  de  origen  del  

usuario  ― El  usuario  es  direccionado  a  la  página  de  auten/cación  de  su  

ins/tución  

Elementos  y  conceptos  de  una  federación  

•  Discovery  Service:  ejemplos  ― Embedded  Discovery  Service  (Shibboleth)  

Elementos  y  conceptos  de  una  federación  

•  Discovery  Service:  ejemplos  ― Embedded  Discovery  Service  ― DiscoJuice  (UNINETT)  

Elementos  y  conceptos  de  una  federación  

•  La  interconexión  de  todas  las  en/dades  

Elementos  y  conceptos  de  una  federación  

Fuente:  SWITCH  AAI-­‐Federa-on      

•  Una  pequeña  analogía  

Elementos  y  conceptos  de  una  federación  

Cómo  funciona  una  federación  

Cómo  funciona  una  federación  

Fuente:  ESR-­‐RNP  

Institución d e l usuario

Cómo  funciona  una  federación  

Institución d e l usuario

Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor

Fuente:  ESR-­‐RNP  

Cómo  funciona  una  federación  

Institución d e l usuario

Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor

Fuente:  ESR-­‐RNP  

Cómo  funciona  una  federación  

Institución d e l usuario

Conexión servidor/servidor Redireccionamiento HTTP Requisición/Respuesta HTTP

Fuente:  ESR-­‐RNP  

Credenciales

Cómo  funciona  una  federación  

Institución d e l usuario

Fuente:  ESR-­‐RNP  

Credenciales

Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor

•  Demostración  de  auten/cación  y  autorización  –  Portal  de  periódicos  CAPES  

Cómo  funciona  una  federación  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

Auten/cación  local  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

Auten/cación  federada  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

•  Demostración  de  auten/cación  y  autorización  –  Portal  CAPES  

Cómo  funciona  una  federación  

•  Demostración  de  Single  Sign-­‐on  

Cómo  funciona  una  federación  

•  Demostración  de  Single  Sign-­‐on  

Cómo  funciona  una  federación  

•  Demostración  de  Single  Sign-­‐on  

Cómo  funciona  una  federación  

•  Servicio  de  teste  de  atributos  

Cómo  funciona  una  federación  

U/lizado  por  el  Portal  de  Periódicos  CAPES  

•  Servicio  de  teste  de  atributos  

Cómo  funciona  una  federación  

U/lizado  por  el  REFEDS  Wiki  

•  Comunicación  entre  los  elementos  ― SAML  (Security  Asser/on  Markup  Language):  Padrón  

que  describe  los  mensajes  XML  enviados  e  recibidos  por  los  elementos  de  la  federación  

― Estos  mensajes  posibilitan  el  cambio  de  datos  para  auten/cación  y  autorización  entre  productores  y  consumidores  de  aserciones  

Cómo  funciona  una  federación  

Definición  de  polí/cas  

•  ¿Qué  es  una  polí/ca?  ― Definición  de  las  reglas  de  una  federación:  cómo  

adherir,  cómo  salir,  obligaciones  y  derechos  de  los  miembros  y  de  la  federación,  etc.  

― Documento  formal  que  define  los  acuerdos  entre  los  miembros  de  una  federación  y  de  ellos  con  la  propia  federación    

― Debe  garan/r  que  la  u/lización  de  los  servicios  no  viole  las  reglas  definidas  por  la  RNIE  o  mismo  por  el  país  del  usuario  

Definición  de  polí/cas  

•  Modelos  de  documentos  de  polí/cas  (inglés)  ―  Iden/ty  Federa/on  Policy:  template  document  

Definición  de  polí/cas  

Fuente:  Iden-ty  Federa-on  Policy:  template  document  

•  Modelos  de  documentos  de  polí/cas  (inglés)  ―  Iden/ty  Federa/on  Policy:  template  document  

Definición  de  polí/cas  

Fuente:  Iden-ty  Federa-on  Policy:  template  document  

•  Modelos  de  documentos  de  polí/cas  (inglés)  ―  Iden/ty  Federa/on  Policy:  template  document  (REFEDS  

Wiki)  

Definición  de  polí/cas  

Fuente:  h^ps://refeds.terena.org/index.php/Iden-ty_Federa-on_Policy_-­‐_template_document  

Ya  compa/ble  com  eduGAIN!  

•  Modelos  de  documentos  de  polí/cas  (inglés)  ―  Iden/ty  Federa/on  Policy:  template  document  -­‐  

hap://www.terena.org/ac/vi/es/eurocamp/oct12/slides/Iden/ty%20Federa/on%20Policy%20Template%20v0.4.pdf    

―  Iden/ty  Federa/on  Policy:  template  document  (REFEDS  Wiki)  -­‐  haps://refeds.terena.org/index.php/Iden/ty_Federa/on_Policy_-­‐_template_document  

Definición  de  polí/cas  

Definición  del  esquema  

•  ¿Qué  es  un  esquema?  ― Colección  de  atributos  que  pueden  calificar  un  objeto  

― Definición  del  nombre  y  formato  de  los  atributos  

― Cada  atributo  debe  tener  un  OID  (Object  Iden8fier)  asociado,  ya  definido,  caso  sea  un  atributo  existente,  o  atribuido  dentro  de  un  registro  definido  para  la  ins/tución    

―  Informaciones  sobre  el  registro  de  atributos:  hap://www.oid-­‐info.com/faq.htm  

Definición  del  esquema  

•  Dependencia  de  los  esquemas  ― Ya  existen  esquemas  definidos  para  algunos  objetos:  

personas,  organizaciones,  eventos,  etc.  

― Se  hay  la  necesitad,  se  puede  registrar  un  nuevo  esquema,  conteniendo  atributos  que  no  aún  existen  y  que  pueden  ser  u/lizados  por  su  federación  

― En  2001,  Internet2  creó  la  primera  versión  de  el  esquema  eduPerson,  para  u/lización  dentro  del  ámbito  académico  

Definición  del  esquema  

•  Esquema  eduPerson  

Definición  del  esquema  

•  Esquema  eduPerson:  ejemplo  de  atributo  creado  

Definición  del  esquema  

•  Esquema  eduPerson:  ejemplo  de  atributo  de  otro  esquema  

Definición  del  esquema  

•  Personalizaciones  del  eduPerson  ― brEduPerson  (Brasil)  ― swissEduPerson  (Suiza)  ― auEduPerson  (Australia)  ― …  y  otras  

― Existen  también  las  federaciones  que  u/lizan  solo  esquemas  ya  definidos,  sin  personalizaciones  

― Esta  es  una  de  las  definiciones  a  se  hacer  en  el  proyecto  de  la  federación  

Definición  del  esquema  

•  Esquemas  más  usados:  ― person:  hap://schema.org/Person  ― eduPerson:  

hap://middleware.internet2.edu/eduperson/docs/internet2-­‐mace-­‐dir-­‐eduperson-­‐201203.html  

― inetOrgPerson:  hap://www.ier.org/rfc/rfc2798.txt  

― SCHAC:  hap://www.terena.org/ac/vi/es/r-­‐emc2/docs/schac/schac-­‐20061212-­‐1.3.0.schema.txt  

•  U/lización  de  esquemas  por  federación:  ― haps://refeds.terena.org/index.php/

Federa/onSchema  

Definición  del  esquema  

Proveedores  de  iden/dad  y  de  servicio  

•  Proveedores  de  servicio  (SP):  en/dades  que  prestan  algún  /po  de  servicio  para  algunos  o  todos  los  miembros  de  una  federación  

•  Después  que  se  hace  la  auten/cación  de  un  usuario,  el  SP  puede  definir  diferentes  perfiles  de  acceso,  que  cambian  de  acuerdo  con  las  informaciones  recibidas  sobre  el  usuario  ― Un  sistema  de  atribución  y    visualización  de  calificaciones  de  

alumnos  en  una  universidad  ―   Un  portal  de  publicaciones  en  que  diferentes  ins/tuciones  

pueden  tener  diferentes  acuerdos  de  permisos  para  sus  miembros  

Proveedores  de  iden/dad  y  de  servicio  

•  Proveedores  de  iden/dad  (IdP):  en/dades  dónde  están  almacenadas  las  informaciones  de  acceso  de  un  usuario  a  la  federación  y  sus  atributos  

•  Es  a  quien  el  proveedor  de  servicios  envía  las  credenciales  digitadas  por  el  usuario  que  intenta  hacer  una  auten/cación  

•  Es  también  quién  realiza  la  auten/cación  del  usuario  

•  Si  la  auten/cación  es  bien  sucedida,  envía  el  token  de  auten/cación  y  los  atributos  del  usuario  al  proveedor  de  servicios  

Proveedores  de  iden/dad  y  de  servicio  

•  Los  proveedores  de  iden/dad  y  de  servicios  son  definidos  en  la  federación  por  medio  de  los  metadatos,  un  archivo  XML  que  con/ene  las  informaciones  que  posibilitan  la  auten/cación  y  el  cambio  de  atributos  

Proveedores  de  iden/dad  y  de  servicio  

•  Ejemplo:  cafe-­‐metadata.xml  

Proveedores  de  iden/dad  y  de  servicio  

•  Estructuras  principales  en  el  archivo  de  metadatos  (Shibboleth  2.X):  ― En88esDescriptor:  es  el  descriptor  de  una  en/dad  o  de  un  

grupo  de  en/dades.  Ejemplo:  un  archivo  de  metadatos,  un  SP  o  un  IdP  

― Role  descriptors:  describen  el  rol  de  la  en/dad  que  está  siendo  descripta.  Roles  importantes  son  <md:IDPSSODescriptor>  y  <md:AaributeAuthorityDescriptor>  cuándo  la  en/dad  en  cues/ón  es  un  IdP,  y  <md:SPSSODescriptor>  para  un  SP  

― Contact  person:  describe  las  informaciones  de  contacto  del  responsable  por  una  en/dad.  Esta  es  la  persona  que  debe  ser  contactada  en  caso  de  problemas  de  auten/cación  a  un  servicio  específico  

Proveedores  de  iden/dad  y  de  servicio  

Discovery  Service  

•  Tiene  por  obje/vo  posibilitar  que  el  usuario  informe  al  proveedor  de  servicios  su  ins/tución  de  origen  

•  Se  puede  u/lizar  de  dos  modos  ― Centralizado  ― A  par/r  del  SP    

Discovery  Service  

•  DS  centralizado  ― Está  dentro  de  la  federación,  con  acceso  a  su  archivo  de  

metadatos  ― Busca  informaciones  sobre  las  ins/tuciones  en  los  

metadatos  de  la  federación  y  al  ofrece  al  usuario  las  opciones  de  ins/tución  

― El  SP  debe  enviar  el  usuario  a  la  página  del  DS  de  la  federación  para  descubrir  la  ins/tución  del  usuario  

Discovery  Service  

•  DS  a  par/r  del  SP  ― Está  en  uno  de  los  SPs  de  la  federación.  El  SP  busca  en  

su  instancia  del  archivo  de  metadatos  las  opciones  posibles  de  IdPs  y  las  presenta  al  usuario  

― El  modelo  u/lizado  para  el  Discovery  Service  puede  ser  elegido  por  la  federación  o  por  el  proveedor  de  servicio  

Discovery  Service  

Discovery  Service  

DS  a  par/r  del  SP  

Discovery  Service  

DS  centralizado  

Discovery  Service  

Cer/ficados  

•  Para  garan/zar  la  confiabilidad  y  permi/r  la  iden/ficación  de  en/dades,  se  puede  u/lizar  la  criptograya  de  llave  pública  para  firmar  los  metadatos  

•  Así,  los  cer/ficados  u/lizados  en  las  en/dades  deben  ser  los  mismos  que  aquellos  presente  en  sus  metadatos  

Cer/ficados  

•  El  Shibboleth  recomienda  la  u/lización  del  cer/ficado  todo  en  los  metadatos  en  vez  de  u/lizar  nombres  y  llaves  públicas  

•  Este  nivel  de  seguridad  y  confiabilidad  es  también  parte  de  las  definiciones  a  se  hacer  para  la  federación  

•  haps://wiki.shibboleth.net/confluence/display/SHIB2/BuildAFedera/on  

Cer/ficados  

Metadatos  de  la  federación  

•  El  archivo  de  metadatos  es  lo  que  define  una  federación  •  Este  archivo  con/ene  todas  las  en/dades  de  la  

federación,  o  sea,  todos  los  metadatos  de  los  SPs  y  IdPs  

Metadatos  de  la  federación  

SP1.xml  

IdP1.xml  

IdP2.xml  

Metadatos.xml    <>  

SP1.xml  IdP1.xml  IdP2.xml  

</>  

•  Cada  en/dad  de  la  federación  debe  decir  que  reconoce  el  archivo  de  la  federación  como  una  fuente  segura  de  datos  de  otros  proveedores  (MetadataProvider)  

•  En  este  archivo,  el  DS  buscará  todos  os  proveedores  de  iden/dad  federados  donde  un  usuario  podrá  auten/carse  

Metadatos  de  la  federación  

•  El  archivo  también  con/ene  informaciones  de  los  IdPs;  así,  el  DS  puede  informar  al  SP  cuál  es  la  dirección  que  él  debe  contactar  para  pedir  la  auten/cación  del  usuario  

•  Un  proveedor  reconoce  otra  en/dad  como  miembro  de  la  federación  comparando  su  nombre  en  el  mensaje  SAML  con  los  nombres  presentes  en  los  metadatos  

Metadatos  de  la  federación  

•  El  archivo  de  metadatos  de  la  federación  puede  ser  construido  de  dos  modos  ― Archivo  único:  todos  los  metadatos  están  concentrados  en  

un  único  archivo,  que  debe  ser  editado  manualmente  siempre  que  un  nuevo  IdP  o  SP  adherir  a  la  federación  

― Archivos  múl/plos:  cada  bloco  de  metadatos  está  en  un  archivo,  dentro  o  fuera  del  dominio  de  la  federación.  En  este  caso,  se  debe  u/lizar  una  herramienta  para  se  agregar  los  metadatos  

•  El  modo  de  manutención  de  los  metadatos  de  las  en/dades  es  también  una  opción  que  se  puede  hacer  en  el  proyecto  de  la  federación  

Metadatos  de  la  federación  

•  Ejemplos  de  herramientas  de  agregación  de  metadatos  ― Shibboleth  Metadata  Aggregator  (en  desarrollo)  ― RepoX  ― OAICat  ― …  y  otros  

Metadatos  de  la  federación  

Ges/ón  de  iden/dad  

•  Una  das  etapas  necesarias  para  asegurar  que  el  concepto  de  federación  sea  mantenido  es  la  ges/ón  de  iden/dad  

•  Esta  es  la  garan_a  de  que  las  cuentas  con  acceso  federado  corresponden  a  personas  que  son  miembros  de  las  ins/tuciones  

•  La  federación  puede  confiar  que  el  IdP  hace  su  propia  ges/ón  o  ayudarlo  a  hacerla  

Ges/ón  de  iden/dad  

•  Desayos  ―  Impedir  el  acceso  de  iden/dades  ar/ficiales  en  la  federación:  

administrador,  cuentas  de  departamento,  cuentas  de  grupos,  roles,  etc.  

― Garan/zar  que  todos  los  usuarios  sean  únicos:  no  se  debe  almacenar  cuentas  duplicadas,  nombres  errados,  registros  duplicados  en  bases  dis/ntas…  

― Garan/zar  que  todos  los  usuarios  tengan  un  vínculo  válido  con  la  ins/tución,  sin  cuentas  expiradas  o  revocadas  

Ges/ón  de  iden/dad  

•  Posibilidades  para  se  hacer  la  ges/ón  en  ins/tuciones  ― Busca  por  datos  y  nombres  duplicados,  data  mining  ―  Iden/ficación  de  cuentas  de  departamento  y  cuentas  

asociadas  a  roles  en  vez  de  personas  ― Desarrollo  de  scripts  personalizados  para  integrar  diferentes  

bases  y  mantener  la  consistencia  y  la  unicidad  de  los  registros  

Ges/ón  de  iden/dad  

Alto  esfuerzo!  

•  Posibilidades  para  se  hacer  la  ges/ón  en  ins/tuciones  ― U/lización  de    una  herramienta  para  hacer  las  operaciones  

de  unificación,  eliminación  de  registros  duplicados  y  sincronización  con  bases  ya  existentes  

Ges/ón  de  iden/dad  

•  Herramienta  para  ges/ón  de  iden/dad  -­‐  EID  ― Sofwares  EID  (Export  Import  Directory  Tool)  &  EID2LDAP:  

unificación  de  bases,  conciliación  de  registros,  sincronización  agentada  de  todas  las  fuentes  de  datos,  populación  de  una  base  LDAP  con  los  registros  ya  tratados  

― Desarrollado  por  la  Universidade  Federal  de  Minas  Gerais  (Brasil)  

― Disponible  en  sourceforge,  solo  en  portugués  

hap://sourceforge.net/projects/eid/  

Ges/ón  de  iden/dad  

•  Herramienta  para  ges/ón  de  iden/dad  -­‐  EID  ― El  EID  construye  un  metadirectorio  a  par/r  de  diferentes  

bases  de  datos:  relacional,  textual,  CSV,  Excel…  

― Con  el  metadirectorio,  es  posible  hacer  la  conciliación  de  registros  aparentemente  duplicados.  Estos  registros  detectados  por  la  herramienta  automá/camente,  pero  el  administrador  debe  decidir  si  son  registros  parecidos  o  los  mismos  registros.  Ejemplo:  homónimos,  gemelos,  nombres  parecidos  

Ges/ón  de  iden/dad  

•  EID:  como  funciona  

Fuente:  ESR-­‐RNP  

Ges/ón  de  iden/dad  

•  EID:  registros  para  conciliación  

Fuente:  ESR-­‐RNP  

Ges/ón  de  iden/dad  

•  EID:  definición  de  un  archivo  CSV  como  fuente  de  datos  

Fuente:  ESR-­‐RNP  

Ges/ón  de  iden/dad  

•  EID:  configuración  del  procesamiento  de  extracción  

Fuente:  ESR-­‐RNP  

Ges/ón  de  iden/dad  

•  EID:  agentamiento  del  procesamiento  

Fuente:  ESR-­‐RNP  

Ges/ón  de  iden/dad  

•  EID:  Procesamiento  del  metadirectorio  ― Después  de  la  creación  del  metadirectorio,  se  puede  crear  un  

nuevo  directorio  LDAP  unificado  u/lizando  el  EID2LDAP  

― La  sincronización  entre  las  bases  an/guas  y  la  nueva  se  hace  por  medio  del  sistema  

― Así,  es  posible  mantener  un  directorio  para  la  federación  sin  alterar  las  configuraciones  de  las  bases  originales  de  la  ins/tución,  consistente  con  los  cambios  hechos  en  estas  bases  

Ges/ón  de  iden/dad  

•  Casos  no  contemplados  por  el  EID  ―  Iden/dades  ar/ficiales  

― Duplicación  de  usuarios  en  diferentes  ins/tuciones  

 

Ges/ón  de  iden/dad  

•  Herramienta  para  ges/ón  de  iden/dad  –  OpenIAM  Iden/ty  Manager  ―  Interesante  para  cuándo  ya  existe  algún  tratamiento  de  las  

iden/dades  dentro  de  la  ins/tución  

― Con/ene  servicios  como  definición  de  polí/cas  de  contraseña,  auditoría,  reportes,  administración  de  cuentas  por  el  usuario  

Ges/ón  de  iden/dad  

•  U/lización  del  AD  ― Una  das  herramientas  de  directorio  u/lizadas  por  las  

ins/tuciones  es  el  AD  

― Problema:  no  es  posible  extraer  directamente  el  vínculo  de  un  usuario  con  la  ins/tución.  Sería  necesario  hacer  una  personalización  de  los  atributos  o  u/lizar  un  script  para  extraer  el  vínculo  de  otra  fuente  

― Ni  siempre  los  responsables  por  los  IdPs  poseen  este  conocimiento  del  directorio  

Ges/ón  de  iden/dad  

•  AD:  Como  hicimos  en  CAFe  ― Muchas  ins/tuciones  nos  pedían  ayuda  sobre  como  

liberar  el  atributo  de  vínculo,  y  no  se  tenía  soporte  oficial  a  directorios  AD  dentro  de  la  federación  

― Solución:  creación  de  un  directorio  paralelo  u/lizando  AD  LDS  y  u/lización  de  un  atributo  adicional  apenas  para  comunicación  entre  AD  y  Shibboleth,  conteniendo  las  informaciones  de  parentesco  

― En  esta  solución,  la  verificación  de  las  credenciales  ocurren  en  el  AD.  Si  fueron  validadas,  los  atributos  del  usuario  son  enviados  al  SP  por  el  AD  LDS  

― El  EID  es  también  compa/ble  con  esa  solución  

Ges/ón  de  iden/dad  

Ges/ón  de  iden/dad  

•  Informaciones  ú/les  sobre  federaciones:    haps://wiki.shibboleth.net/confluence/display/SHIB2/Home  

•  Guías  de  instalación    hap://www.switch.ch/aai/support/iden/typroviders/    hap://www.switch.ch/aai/support/serviceproviders/    

Páginas  ú/les  

Muchas  gracias!  

Camila  Santos  Analista  en  TIC  <[email protected]>        Directoría  Adjunta  de  Ges-ón  de  Servicios  (DAGSer)  Rede  Nacional  de  Ensino  e  Pesquisa  (RNP)