...
Si on propose dans nos documentations de monter un mod_shib avec Apache pour proposer une authentification fédérée via la fédération d'identités ESR, vous pouvez en réalité utiliser d'autres mécansimes/briques (et même d'autres frontaux) du moment que vous renvoyez en tant que REMOTE_USER le 'username' de l'utilisateur - qui doit être l'eduPersonPrincipalName (eppn) ou l'équivalent, c'est à dire un identifiant unique et pérenne inter-établissements (eppn correspondant à uid_local@le_domaine).
Aussi, plutôt que d'utiliser sous Apache, mod_shib, vous pouvez par exemple utiliser mod_auth_openidc pour faire de l'openId connect, ou mod_auth_cas pour utiliser le protocole CAS, mod_authnz_ldap pour ldap, etc.
...
Pour la partie SQL, le paramétrage de la requpête SQL complète rend la chose plus souple, on peut par exemple faire un where uid = replace(?, '@univ-ville.fr', '') ; la aussi, il faut indexer la colonne sql sur laquelle le where est effectué.
Note supplémentaire : esup-sgc permet à un utilisateur existant dans le SI de disposer d'une carte dans le SGC. Un utilisateur existant correspond à une entrée dans un des "UserInfoService" que vous aurez configuré avec donc a minima un eduPersonPrincipalName (ou équivalent uid_local@domaine). ESUP-SGC garantit ainsi une cohérence du SI en ne déstructurant pas votre SI, puisque chaque carte est relié à une entité compte utilisateur renseignée dans le SI. En utilisant eduPersonPrincipalName cependant ici comme identifiant des comptes détenant les cartes, on tend ici cependant à généraliser l'usage d'eduPerson (dont est issu eduPersonPrincipalName) à l'ensemble des comptes du SI, et pas seulements aux seuls "personnes humaines" comme recommandé.
Les serveurs ESUP-SGC et ESUP-NFC-TAG sont shibbolethisés, leur déclaration en tant que Service Provider dans la fédération d'identités Renater est donc obligatoire ?
...