• Documentation SIRTFI, RENATER

Au niveau du SP, il est possible de mettre en place un filtrage des utilisateurs basé sur SIRTFI. L’idée ici est de restreindre l’accès à une ressource uniquement aux utilisateurs authentifiés auprès d’un IdP conforme SIRTFI.

D’un point de vue technique, ce filtrage pourra être réalisé de deux manières différentes :

1. Soit par l’application directement (en utilisant la logique de contrôle d’accès de l’application) ;
2. Soit via l’utilisation de la fonctionnalité de filtre offerte par le SP Shibboleth

Dans les deux cas, il faudra au préalable récupérer l’Entity Attribute SIRTFI côté SP.

Les attributs de type « Entity Attribute » sont listés dans les métadonnées de la fédération. Ils peuvent être mappés au niveau du SP de manière identique à ce qu’il est possible de faire pour les attributs utilisateur délivrés par un IdP.

Pour pouvoir utiliser les attributs présents dans les métadonnées, il est d’abord nécessaire de définir un préfixe spécifique dans la balise ApplicationDefaults (ou ApplicationOverride) du fichier de configuration shibboleth2.xml, comme illustré ci-dessous :

shibboleth2.xml

<ApplicationDefaults entityID=https://example.org/shibboleth/
metadataAttributePrefix="md_">

Supposons qu’un entity attribute SIRTFI soit renseigné pour un IdP dans les métadonnées :

<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
  <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                  Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">
           <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue>
  </saml:Attribute>
</mdattr:EntityAttributes>

Il est alors possible de définir un mapping de cet attribut au niveau du SP, dans le fichier attribute-map.xml, de la manière suivante :

attribute-map.xml

<Attribute name="urn:oasis:names:tc:SAML:attribute:assurance-certification" id="sirtfi" />

Ce qui permet à la valeur de l’attribut défini ci-dessus d’être disponible au travers de la variable md_sirtfi.

Une fois la variable md_sirtfi récupérée au niveau du SP, la valeur associée peut être passée à l’application.
Si vous avez la possibilité de modifier le code source de l’application, il est alors envisageable d’implémenter un contrôle d’accès se basant sur la vérification de cette valeur.

Comme solution alternative, il est également possible d’utiliser la fonctionnalité de filtre offerte par le SP Shibboleth.
Au niveau d’Apache, cela requiert de définir un élément directory (/limit/access) sur lequel on souhaite appliquer un contrôle d’accès et où sont positionnées les règles d’autorisations (path/to/ac.xml)

<Directory /limit/access>
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibAccessControl /path/to/ac.xml 
</Directory>

La configuration du filtre du SP Shibboleth est défini au travers du fichier /path/to/ac.xml, dont un exemple est fourni ci-dessous :

Exemple de filtre simple vérifiant que l’utilisateur est un étudiant authentifié sur un IdP Sirtfi :

<AccessControl type="edu.internet2.middleware.shibboleth.sp.provider.XMLAccessControl">
   <AND>
      <Rule require="md_sirtfi"> https://refeds.org/sirtfi </Rule>
      <RuleRegex require="affiliation">^student@.+\.cz$</RuleRegex>   		
   </AND>
</AccessControl>

L’exemple ci-dessus reste assez basique mais il est possible d’implémenter des règles de contrôle d’accès plus complexes. Plus de détails dans la documentation Shibboleth:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPXMLAccessControl