Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
docpublic:systemes:shibboleth:idpv2 [2010/01/03 11:25]
127.0.0.1 external edit
docpublic:systemes:shibboleth:idpv2 [2010/05/11 20:20] (current)
PROCACCIA
Line 1: Line 1:
--- Main.JehanProcaccia - 20 Mar 2008+====== IdP-ShibV2 ======
  
- +===== Références shib v2 =====
-===== Références+
  
 http://shibboleth.internet2.edu/shib-v2.0.html http://shibboleth.internet2.edu/shib-v2.0.html
Line 8: Line 7:
 https://spaces.internet2.edu/display/SHIB2/Home https://spaces.internet2.edu/display/SHIB2/Home
  
-mail:+mail d'annonce:
 <code> <code>
 Date - Thu Mar 20 07:40:01 2008 Date - Thu Mar 20 07:40:01 2008
Line 17: Line 16:
 </code> </code>
  
-===== Pre-requis+===== Pre-requis ===== 
 + 
 +Logiciels nécessaires 
 + 
 + 
 +==== Java ====
  
-==== Java+un JDK , sun de préférence:
  
 <code> <code>
Line 32: Line 36:
    * </code>    * </code>
  
-=== Environement java+=== Environement java ===
  
 Sous CEntos/redhat le JRE et JDK installent java dans */usr/lib/jvm/java* Sous CEntos/redhat le JRE et JDK installent java dans */usr/lib/jvm/java*
Line 46: Line 50:
 </code> </code>
  
-==== Tomcat+==== Tomcat ==== 
 + 
 +un serveur d'application java, ici tomcat:
  
 <code> <code>
Line 80: Line 86:
 </code> </code>
  
-===== IDP v2.0+===== IDP v2.0 =====
  
-==== Download+==== Download ====
  
 <code> [root@shibidp1 /usr/local/src] <code> [root@shibidp1 /usr/local/src]
Line 104: Line 110:
 </code> </code>
  
-==== Preparation JVM+==== Preparation JVM ====
  
 from https://spaces.internet2.edu/display/SHIB2/IdPPrepareJVM from https://spaces.internet2.edu/display/SHIB2/IdPPrepareJVM
  
-=== librairie jar+=== librairie jar ===
  
 <code> <code>
Line 118: Line 124:
 </code> </code>
  
-=== Security provider+=== Security provider ===
  
 <code> <code>
Line 139: Line 145:
 </code> </code>
  
-==== Preparation Tomcat+==== Preparation Tomcat ====
  
-=== Endorse Xerces and Xalan+=== Endorse Xerces and Xalan ===
  
 https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare
Line 167: Line 173:
 </code> </code>
  
-=== Memory usage +=== Memory usage === 
 + 
 <code> <code>
 [root@shibidp1 /etc/tomcat5] [root@shibidp1 /etc/tomcat5]
Line 175: Line 181:
 </code> </code>
  
-=== hostname server.xml+=== hostname server.xml ===
  
 remplacement du defaut *localhost* pa le hostname . remplacement du defaut *localhost* pa le hostname .
Line 188: Line 194:
 mais probleme, car du coup les webapps déclarées dans */etc/tomcat5/Catalina/localhost/* ne sont plus lancée, ont l'idp !. bref retour a localhost finalement ... mais probleme, car du coup les webapps déclarées dans */etc/tomcat5/Catalina/localhost/* ne sont plus lancée, ont l'idp !. bref retour a localhost finalement ...
  
-=== Connecteur+=== Connecteur ===
  
 <code> <code>
Line 212: Line 218:
 </code> </code>
  
-=== Context Deployment Fragment+=== Context Deployment Fragment ===
  
 Il s'agit d'un petit code xml qui indique a tomcat où se trouvre le WAR et fournis des proprietés de chargement de l'application par tomcat. cela evite l'auto-deployement par tomcat qui parfois pose pb avec le cache tomcat .Cette arborescence /opt/shibboleth-idp/war/ sera créée dans le chapitre suivant, lors de l'installation de shibboleth IDP ... Il s'agit d'un petit code xml qui indique a tomcat où se trouvre le WAR et fournis des proprietés de chargement de l'application par tomcat. cela evite l'auto-deployement par tomcat qui parfois pose pb avec le cache tomcat .Cette arborescence /opt/shibboleth-idp/war/ sera créée dans le chapitre suivant, lors de l'installation de shibboleth IDP ...
Line 230: Line 236:
 </code> </code>
  
-==== Connecteur AJP apache - tomcat+==== Connecteur AJP apache - tomcat ====
  
 Afin de ne pas trainer les URL vers tomcat avec les :8080 ou :8433 , on met en place le proxy-ajp d'apache qui redirigera les requetes en */idp* vers les context */idp* dans tomcat Afin de ne pas trainer les URL vers tomcat avec les :8080 ou :8433 , on met en place le proxy-ajp d'apache qui redirigera les requetes en */idp* vers les context */idp* dans tomcat
Line 240: Line 246:
 </code> </code>
  
-==== Installation+==== Installation ====
  
 Lancement du *install.sh* , le JAVA_HOME etant definit au préalable !. Lancement du *install.sh* , le JAVA_HOME etant definit au préalable !.
Line 294: Line 300:
 idp.hostname=shibidp1.it-sudparis.eu</code>L'installation a créé l'arborescence de l'IdP Shibboleth sous le répertoire /opt/shibboleth-idp/. Cette arborescence doit être accessible pour l'utilisateur qui exécute le serveur Tomcat, dans notre cas l'utilisateur tomcat<br /><verbatim> $ chown -R tomcat /opt/shibboleth-idp/</verbatim> idp.hostname=shibidp1.it-sudparis.eu</code>L'installation a créé l'arborescence de l'IdP Shibboleth sous le répertoire /opt/shibboleth-idp/. Cette arborescence doit être accessible pour l'utilisateur qui exécute le serveur Tomcat, dans notre cas l'utilisateur tomcat<br /><verbatim> $ chown -R tomcat /opt/shibboleth-idp/</verbatim>
  
-==== Lancement+==== Lancement ====
  
 lors du premier lancement de tomcat une fois l'IDP deployé les log tomcat indiques: lors du premier lancement de tomcat une fois l'IDP deployé les log tomcat indiques:
Line 317: Line 323:
  
  
-=== Log shibboleth+=== Log shibboleth ===
  
 Pendant la pahese d'installation et parametrage il est oportunt de mettre en mode DEBUG l'IDP : Pendant la pahese d'installation et parametrage il est oportunt de mettre en mode DEBUG l'IDP :
Line 336: Line 342:
  
  
-===== Parametrage de l'IDP+===== Parametrage de l'IDP =====
  
 Les fhichiers de configuration XML se trouvent dans */opt/shibboleth-idp/conf/* Les fhichiers de configuration XML se trouvent dans */opt/shibboleth-idp/conf/*
  
-==== relying-party.xml+==== relying-party.xml ====
  
 Le fichier de configuration principal (avant (1.3) s'etait idp.xml qui a été eclaté en relying-party.xml, handler.xml ...)  Le fichier de configuration principal (avant (1.3) s'etait idp.xml qui a été eclaté en relying-party.xml, handler.xml ...) 
Line 367: Line 373:
  
  
-==== Metadata pour Féderation Cru-Test+==== Metadata pour Féderation Cru-Test ====
  
 Téléchargez le certificat utilisé pour signer les méta-données du CRU : Téléchargez le certificat utilisé pour signer les méta-données du CRU :
Line 429: Line 435:
 http://shibidp1.it-sudparis.eu/idp/profile/Status http://shibidp1.it-sudparis.eu/idp/profile/Status
  
-==== Metada fédération Renater+==== Metada fédération Renater ====
  
 https://federation.renater.fr/technique/configurations https://federation.renater.fr/technique/configurations
Line 484: Line 490:
 </code> </code>
  
-=== Metadata JASIG+=== Metadata JASIG ===
  
 Exemple precedent depuis la doc jasig ... pour l'histoire ... Exemple precedent depuis la doc jasig ... pour l'histoire ...
Line 505: Line 511:
  
  
-==== Enregistrement fédération test Renater+==== Enregistrement fédération test Renater ====
  
 https://federation.renater.fr/test/enregistrement https://federation.renater.fr/test/enregistrement
 https://services-federation.renater.fr/gestion https://services-federation.renater.fr/gestion
  
-===== Authentification Utilisateur via CAS+===== Authentification Utilisateur via CAS =====
  
-==== Installation du client CAS+==== Installation du client CAS ====
  
-=== Maven+=== Maven ===
  
 L'utilitaire de "construction" preconisé est maintenant maven, il faut donc l'installer . L'utilitaire de "construction" preconisé est maintenant maven, il faut donc l'installer .
Line 557: Line 563:
  
  
-=== Client CAS+=== Client CAS ===
  
 Nous pouvons maintenant télécharger les sources du client CAS et le compiler: Nous pouvons maintenant télécharger les sources du client CAS et le compiler:
Line 648: Line 654:
 </code> </code>
  
-=== Filtre CAS+=== Filtre CAS ===
  
 ajouter l'appel au filtre CAS dans le web.xml des sources de l'IdP puis regénérer le fichier idp.war. ajouter l'appel au filtre CAS dans le web.xml des sources de l'IdP puis regénérer le fichier idp.war.
Line 687: Line 693:
 </code> </code>
  
-=== erreur "Metadata's validity interval"+=== erreur "Metadata's validity interval" ===
  
 Il se peut qu'apres rechargement de l'idp par tomcat dans idp-porcess.log on ait cette erreur Il se peut qu'apres rechargement de l'idp par tomcat dans idp-porcess.log on ait cette erreur
Line 701: Line 707:
 maxValidityInterval="604800000" /> => on a ajouter ici 3x0  maxValidityInterval="604800000" /> => on a ajouter ici 3x0 
  
-===== Distribution d'Attributs+===== Distribution d'Attributs =====
  
-=== Configuration de l'attribut resolver+=== Configuration de l'attribut resolver ===
  
 Connecteur ldap Connecteur ldap
Line 743: Line 749:
  
  
-=== Filtrage des attributs transmis+=== Filtrage des attributs transmis ===
  
 Attribut que l'on souhaites distribuer aux Services Provider shibboleth. Attribut que l'on souhaites distribuer aux Services Provider shibboleth.
Line 797: Line 803:
 </code> </code>
  
-=== Test de l'attribute resolver+=== Test de l'attribute resolver ===
  
 Le script *aacli.sh* permet de tester l'interrogation et la restitution d'attributs: Le script *aacli.sh* permet de tester l'interrogation et la restitution d'attributs:
Line 841: Line 847:
  
  
 +=== Construction d'attributs ===
  
 +== Mapped ==
  
-===== Test de l'IDP+Si l'annuaire n'est pas encore compatible supann/eduperson , on peux creer des attribut compatibles (ici eduPersonAffiliation) sur la base d'attributs pre-existants (ici employeeType) . 
 +Exemple
  
-==== Enregistrement aupres d'une fédération+<code> 
 +<!-- https://spaces.internet2.edu/display/SHIB2/ResolverMappedAttributeDefinition --> 
 +<resolver:AttributeDefinition xsi:type="Mapped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
 +                             id="eduPersonAffiliation" 
 +                             sourceAttributeID="employeeType"> 
 +   <resolver:Dependency ref="myLDAP" /> 
 +       <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
 +           name="urn:mace:dir:attribute-def:eduPersonAffiliation" /> 
 +       <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
 +           name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" /> 
 +    <!-- default to the generic value 'affiliate' --> 
 +    <DefaultValue>affiliate</DefaultValue> 
 +    <!-- map internal values like 'student-worker' and 'undergraduate' to 'student' --> 
 +    <ValueMap> 
 +        <ReturnValue>employee</ReturnValue> 
 +        <!--<SourceValue ignoreCase="true">CN=.*,ou=permanents,dc=people,dc=mysite,dc=fr</SourceValue> --> 
 +        <SourceValue ignoreCase="true">permanent</SourceValue> 
 +    </ValueMap> 
 +       <!-- map your internal 'Institut' value to 'invite' --> 
 +    <ValueMap> 
 +        <ReturnValue>invite</ReturnValue> 
 +        <SourceValue>Institut</SourceValue> 
 +    </ValueMap> 
 +       <!-- map your internal 'CDD' value to 'member' --> 
 +    <ValueMap> 
 +        <ReturnValue>member</ReturnValue> 
 +        <SourceValue>CDD</SourceValue> 
 +    </ValueMap> 
 +       <!-- map your internal 'Doctorant' value to 'member' --> 
 +    <ValueMap> 
 +        <ReturnValue>member</ReturnValue> 
 +        <SourceValue>Doctorant</SourceValue> 
 +    </ValueMap> 
 +</resolver:AttributeDefinition>  
 +</code> 
 + 
 + 
 +== Expression reguliere == 
 + 
 +construction d'un attribut sur la base d'une dn de branche ldap => split REgex : 
 + 
 +<code> 
 +<!-- https://spaces.internet2.edu/display/SHIB2/ResolverRegexSplitAttributeDefinition --> 
 +<resolver:AttributeDefinition xsi:type="RegexSplit" xmlns="urn:mace:shibboleth:2.0:resolver:ad" 
 +                              id="employeeType" 
 +                              sourceAttributeID="distinguishedName" 
 +                              regex=".*,OU=([^,]*),DC=people,DC=mysite,DC=fr"> 
 +        <resolver:Dependency ref="tl1AD" /> 
 +     <!-- Remaining configuration from the next step goes here --> 
 +        <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
 +            name="urn:mace:dir:attribute-def:employeeType" /> 
 +        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
 +            name="urn:oid:2.16.840.1.113730.3.1.4" friendlyName="employeeType" /> 
 +</resolver:AttributeDefinition> 
 +</code> 
 + 
 +===== Test de l'IDP ===== 
 + 
 +==== Enregistrement aupres d'une fédération ====
  
 il faut un Service Provider pour tester notre fournisseur d'identité (IDP), pour faire simple dans un premier temps, nous allons utiliser un fournisseur de service Test  du CRU, mais il faut au préalable enregisterer notre nouvel IDP dans la federation de Test du CRU : il faut un Service Provider pour tester notre fournisseur d'identité (IDP), pour faire simple dans un premier temps, nous allons utiliser un fournisseur de service Test  du CRU, mais il faut au préalable enregisterer notre nouvel IDP dans la federation de Test du CRU :
Line 865: Line 932:
  
  
-==== Login sur un SP de test+==== Login sur un SP de test ====
  
 https://federation.cru.fr/sp-test https://federation.cru.fr/sp-test
Line 873: Line 940:
 On obtient alors un acces authentifié ainsi qu'un "push" d'attributs , ceux declaré dans l'attreibute filter ! On obtient alors un acces authentifié ainsi qu'un "push" d'attributs , ceux declaré dans l'attreibute filter !
  
-=== Résultat dans le navigateur +=== Résultat dans le navigateur === 
 + 
 <code> <code>
 -shib- -shib-
Line 941: Line 1008:
 </code> </code>
  
-=== Log IDP+=== Log IDP ===
  
 <code> <code>
Line 984: Line 1051:
 </code> </code>
  
-==== Configuration du RemoteUser+==== Configuration du RemoteUser ====
  
 Il faut utiliser le "handler" RemoteUser : cf https://mail.internet2.edu/wws/arc/shibboleth-users/2008-03/msg00500.html Il faut utiliser le "handler" RemoteUser : cf https://mail.internet2.edu/wws/arc/shibboleth-users/2008-03/msg00500.html
Line 1013: Line 1080:
  
  
-==== Filtre d'acces /Authn/RemoteUser CAS+==== Filtre d'acces /Authn/RemoteUser CAS ====
  
 on filtre dans le *web.xml* l'acces au context * /Authn/RemoteUser* vers notre CAS local on filtre dans le *web.xml* l'acces au context * /Authn/RemoteUser* vers notre CAS local
Line 1057: Line 1124:
 </code> </code>
  
-===== Certification+===== Certification =====
  
 Au premier abord on tombe sur des besoins de confiances (transfert securisés) entre SP et IDP . Sans aucune prise en compte des certificats/keystore, l'IDP genere alors ce type d'erreur dans ces log *idp-process.log* justement a propos de chaine de certification: Au premier abord on tombe sur des besoins de confiances (transfert securisés) entre SP et IDP . Sans aucune prise en compte des certificats/keystore, l'IDP genere alors ce type d'erreur dans ces log *idp-process.log* justement a propos de chaine de certification:
Line 1069: Line 1136:
 </code> </code>
  
-==== Chaine de certification+==== Chaine de certification ====
  
 On procede alors a la création d'un keystore qui comprend le certificat et la clé de notre serveur, ainsi que le chaine de certification (ici au format openssl pkcs12 afin de s'affranchir des commandes esoteriques JDK ...avis perso ;-) ) . On procede alors a la création d'un keystore qui comprend le certificat et la clé de notre serveur, ainsi que le chaine de certification (ici au format openssl pkcs12 afin de s'affranchir des commandes esoteriques JDK ...avis perso ;-) ) .
Line 1080: Line 1147:
 </code> </code>
  
-==== tomcat sur 8443+==== tomcat sur 8443 ====
  
 Il faut alors indiquer au serveur d'application tomcat via *server.xml* de repondre au demandes d'attribut sur une port sécurisé (8443) qui justement utilisera ce keystore. Il faut alors indiquer au serveur d'application tomcat via *server.xml* de repondre au demandes d'attribut sur une port sécurisé (8443) qui justement utilisera ce keystore.
Line 1102: Line 1169:
 </code> </code>
  
-==== SunJVM truststore+==== SunJVM truststore ====
  
 enfin il faut que le JVM qui tourne tomcat ait confiance en notre autorité qui a signée notre serveur, ici tmsp_ca à signé shibidp1.it-sudparis.eu (shibidp1_tmsp.pem !), on ajoute donc cette autorité a celles bien connus deja presentes dans le *cacerts* livré avec la JVM sun: enfin il faut que le JVM qui tourne tomcat ait confiance en notre autorité qui a signée notre serveur, ici tmsp_ca à signé shibidp1.it-sudparis.eu (shibidp1_tmsp.pem !), on ajoute donc cette autorité a celles bien connus deja presentes dans le *cacerts* livré avec la JVM sun:
Line 1119: Line 1186:
 </code> </code>
  
-===== SSO shibboleth et AD+===== SSO shibboleth et AD ====
  
 pour un site ne disposant au préalable d'un SSO (CAS souvent !) , shibboleth offre un service interne de SSO. pour un site ne disposant au préalable d'un SSO (CAS souvent !) , shibboleth offre un service interne de SSO.
Line 1126: Line 1193:
 Nous utiliserons alors le systeme SSO interne a shibboleth plutot que de s'appuyer sur une SSO externe comme CAS. Nous utiliserons alors le systeme SSO interne a shibboleth plutot que de s'appuyer sur une SSO externe comme CAS.
  
-==== doc de reference+==== doc de reference ====
  
 https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass et pour AD https://spaces.internet2.edu/display/SHIB2/IdPADConfigIssues https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass et pour AD https://spaces.internet2.edu/display/SHIB2/IdPADConfigIssues
  
-==== LoginHandler UsernamePassword+==== LoginHandler UsernamePassword ====
  
 il faut activer le LoginHandler UsernamePassword dans handler.xml et commenter le LoginHnadler RemoteUser, autrement c'est ce dernier qui prend la main . il faut activer le LoginHandler UsernamePassword dans handler.xml et commenter le LoginHnadler RemoteUser, autrement c'est ce dernier qui prend la main .
Line 1146: Line 1213:
 </code> </code>
  
-=== JAAS configuration file+=== JAAS configuration file ===
  
 c'est ici qu'on definit le moyen d'aller rechercher une authentification sur AD c'est ici qu'on definit le moyen d'aller rechercher une authentification sur AD
Line 1169: Line 1236:
 </code> </code>
  
-==== Attributes resolver+==== Attributes resolver ====
  
 Il faut definir un resolver pour recuperer les attributs Il faut definir un resolver pour recuperer les attributs
  
-=== connecteur+=== connecteur ===
  
 <code> <code>
Line 1191: Line 1258:
 </code> </code>
  
-=== definition des attributs+=== definition des attributs ===
  
 <code> <code>
Line 1220: Line 1287:
 </code> </code>
  
-=== Filtres+=== Filtres ===
  
 A partir des attributs resolus ci-dessus on peut definir des politiques de diffusion de ces derniers, par liste de Service Provider par exemple : A partir des attributs resolus ci-dessus on peut definir des politiques de diffusion de ces derniers, par liste de Service Provider par exemple :
Line 1358: Line 1425:
 Shib_Authentication_Method=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Shib_Authentication_Method=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
 </code> </code>
 +
 +création JehanProcaccia - 20 Mar 2008
 +
  
docpublic/systemes/shibboleth/idpv2.1262517921.txt.gz · Last modified: 2010/01/03 11:32 (external edit)
[unknown link type]Back to top
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0