Evolution #3280
Accès au entêtes du bloc HTTP pour les fonctions de création des attributs calculés eole SSO
0%
Description
Nous avons besoin d'avoir accès aux données d'entête du bloc http dans les fonctions de création des attributs calculés pour répondre à des problématiques particulières:
ex pour l'accès au pia, nous utilisons différents reverse-proxy en fonction du réseau de connexion (ac, in ou agriates), les accès sont autorisés par le firewall en fonction de ces réseaux. Il suffira donc au reverse proxy d'écrire une donnée d'entête particulière (ex: lansrc avec pour contenu in ou ac ou agriates), affecter un attribut avec ce contenu à travers une fonction users_info du SSO et et ainsi créer des profils posh particulier pour attaquer arena comme il faut... Contrairement au données d'entête placées par le navigateur lui-même (ip_locale par exemple) ces données sont placées par notre architecture donc sécurisées (pas de doute sur la véracité du contenu).
Merci.
Demandes liées
Historique
#1 Mis à jour par Lionel Morin il y a presque 14 ans
- Projet changé de Envole à EoleSSO
- Version cible
Envole 3.2.1 Stablesupprimé
#2 Mis à jour par Bruno Boiget il y a presque 14 ans
- Statut changé de Nouveau à Ne sera pas résolu
Vu avec Pascal et Christophe Léon.
A priori cette fonctionnalité n'est pas nécessaire pour répondre à ses besoins. La fonctionnalité peut être obtenue en analysant les entêtes HTTP sur l'application dispatcher, et en utilisant les informations contenues dans les attributs utilisateur (en particulier le service demandé par l'utilisateur).
Conclusion de la conversation :
Salut,
Effectivement, cela semble plus logique de se baser sur l'URL de service, pour faire ce que tu souhaites
Car je ne suis pas certains que tu récupères tout dans les entêtes, se pose de plus le pb de https
J'avais déjà fait un signalement à Bruno à ce sujet, pour récupérer l'url de service dans les attributs calculés
Sur la dernière maj EoleSSO, la modification est présente.
Ligne 115 de /usr/share/sso/authserver.py
# si le ticket d'application est connu, on passe également le service à atteindre dans les attributs
if ticket:
infos['service_url'] = ticket.service_url
Donc dans des attributs calculés tu récupères l'info comme ça : service_url=user_infos.get('service_url','')
++ Christophe
> Le 12/04/2012 15:44, Christophe LEON a écrit :
>>
>> Bonjour,
>>
>>
> Bonjour,
>
>> J'ai également pensé que l'on pouvait peut être dans le cas de l'utilisation d'un reverse proxy réécrire l'url de redirection de l'application vers le serveur sso pour permettre de nouveau un passage par le reverse proxy:
>> lors de l'accès au SSO par le navigateur (l'appli redirige vers https://pia:8443 le proxy intercepte la réponse et ré-écrit la redirection vers pia:4443 cette url permet de repasser par le reverse proxy qui redirige vers pia:8443 en ajoutant au passage une donnée d'entête (IN AC ou AGRIATES). mais là faut faire des tests car je sais pas si ça peut fonctionner.
> Bien entendu, en https cela ne va pas le faire...
>
> Par contre en faisant passer des données supplémentaires dans l'url de retour de l'application (par le reverse proxy sur la réponse de l'appli) et ensuite y avoir accès dans le bloc d'info des attribues calculés... ça peut fonctionner... peut être.
> Donc en fonction du reverse proxy traversé je peux faire remonter une info différente.
> Il faudra peut être réécrire l'url pour supprimer ces infos à la reconnexion du navigateur (avec son ticket) au niveau du reverse proxy si ça gène l'appli (posh en l’occurrence).
>
> Qu'en penses-tu, ça peut fonctionner ?
>
> Merci pour ton aide.
>
>> Je n'arrive pas très bien à comprendre ton fonctionnement.
>>
>> Tu souhaites récupérer les entêtes HTTP dans les filtres d'attributs pour calculer des valeurs particulière en fonction de ces entêtes ?
>>
>> Ceci n'est d’intérêt que si ton serveur SSO se trouve derrière un reverse-proxy. est-ce bien le cas ?
>> EN effet le serveur Web d'Eole SSO, ne pourra te fournir que les entêtes HTTP aux requêtes qu'il répond
>>
>> Je m'explique :
>>
>> L'utilisateur A fait une requete sur le service PIA qui se trouve derriere un reverse-proxy Rprox
>>
>> A -> Rprox -> PIA
>>
>> PIA est CASSifier, donc PIA retourne A vers EOle SSO
>> Le navigateur de A fait donc un appel au service SSO en précisant l'URL de service PIA (A ce moment je ne voies pas pour quelle raison le navigateur de A va envoyer dans ses entêtes HTTP qu'il est passé par un reverse proxy pour accéder a PIA) [ ce serait d'ailleurs un pb de sécu ]
>>
>> Donc EoleSSO voit une requête venant de A qui demande l'accès a une ressource PIA
>>
>> A moins que je n'ai pas compris ton besoin
>>
>> Chez nous Seshat (EoleSSO) est en directe sur Internet, différent service sont derrière différent revers-proxy.
>> Par exemple pour l'accès au LPC.
>>
>> j’appelle une page http://seshat.ac-reunion.fr/dispatcher/lpc.php
>> Pour accéder a cette page soit il arrive de l'internet (Revers-proxy) soit du réseau administratif (@IP admin) soit du réseau péda (Proxy AMON)
>> J'analyse les entêtes HTTP je regarde le Xforwarded-for et l'@IP
>> en fonction je fais une redirection sur le bon portail.
>>
>> En espérant avoir pu t'éclairer,
>> donne moi des précisions sur ta demande, je n'arrive pas a bien cerné
>>
>> Bon courage
>> ++ Christophe