FIXME

Page en cours de construction

8. Mise en œuvre d'un proxy SP

8.1. Shibboleth SP en mode proxy

Rien n'oblige d'installer Shibbboleth SP et Apache à chaque fois qu'une application doivent être ouverte sur la Fédération Éducation-Recherche. En effet, comme cela a été dit précédemment, on peut déclarer dans Shibboleth plusieurs contextes applicatifs. Ces notions d' “Application” dans Shibboleth sont uniquement une factorisation de paramètres. Il est donc tout à fait valable de placer “derrière” Shibboleth plusieurs applications (au sens général), mais en ne déclarant qu'un seul Service Provider dans le guichet de la fédération.

Il n'est pas toujours souhaitable de “masquer” N applicatifs derrière un seul SP (au sens déclaration sur le Guichet), car cela peut empêcher un IdP de bloquer explicitement l'accès à un applicatif pour tout ou partie de ces utilisateurs.
Les bonnes pratiques pour choisir entre 1 ou N SP sont décrites ici : https://wiki.shibboleth.net/confluence/display/SP3/ApplicationOverride#ApplicationOverride-ValidandInvalidReasonsforOverrides.


Shibboleth SP et Apache peuvent être donc être configurés comme mandataires (proxy) pour plusieurs applications. Le mode de fonctionnement est basé sur une proxification HTTP standard ; Shibboleth se chargeant d'inclure dans les headers HTTP les valeurs extraites des assertions SAML.
Charge à l'application de base ses mécanismes d'autorisation sur ces headers.

D'un point de vue sécurité, il est indispensable que les applications situées derrière Shibboleth ne soient pas accessibles directement par les utilisateurs, car certains pourraient inlure eux-même les headers normalement positionnés par Shibboleth et bypasser l'authentification.

8.2. Shibbolisation d'une application non SAML

FIXME Framadate ?