L'API d'authentification CAS REST accepte le texte/* mais pas l'application/* type de contenu

Question

J'ai configuré mon serveur CAS pour activer l'authentification REST, conformément au these instructions. Cependant, pour que cela fonctionne, je dois soumettre mes informations d'identification en texte clair (type de contenu text/html ou xml) et non application/x-www-form-urlencoded selon les instructions. Les informations d'identification sont perdues lorsqu'elles sont envoyées dans ce dernier format. Je ne suis pas à l'aise d'envoyer mes identifiants de connexion en texte brut. Est-ce un bug dans CAS et comment peut-il être corrigé? Je suppose qu'il est moins sûr d'envoyer des identifiants de connexion que le type de contenu de texte par rapport à l'application, car ce dernier (je suppose) fait hash (ou d'une autre manière obscurcit) le contenu envoyé.

Je devrais également mentionner que j'ai dû faire une correction à un bogue dans le CAS en raison de quelles qualifications étaient perdues indépendamment du type de contenu, en mettant en application this solution dans mon maven overlay. Après cela, seuls les types de contenu basés sur du texte ont fonctionné et CAS a pu s'authentifier (bien que je trouve ennuyeux que le service renvoie du HTML et non du XML/JSON ou même du texte, pour faciliter le traitement programmatique).

CONNEXES:REST API endpoint /v1/tickets appears to lose credential request parameters

Answer 1

Content-Type n'a aucun effet sur la confidentialité des données dans la demande. L'envoyer avec application/x-www-form-urlencoded dans une requête n'est pas plus (ni moins) sécurisé que text/html ou text/xml si seule la confidentialité est considérée. Il n'y a aucune valeur de sécurité supplémentaire dans l'utilisation de l'un de ceux dans une requête, quelqu'un ayant accès à la source de requête brute (un attaquant MitM) verra le contenu de la requête de toute façon. HTTPS atténue efficacement ce risque en ce qui concerne les attaquants MitM sur le réseau entre nœuds, mais pas sur les terminaux où le protocole SSL est terminé (les ordinateurs source et cible, ainsi que tout nœud qui termine SSL, comme par exemple un proxy d'entreprise avec une racine approuvée certificat sur les clients - une configuration assez commune).

En ce qui concerne la sécurité possible des avantages de l'utilisationtext/plain au lieu de application/x-www-form-urlencoded, s'il vous plaît voir my answer à votre autre question. En résumé, l'utilisation de text/plain peut empêcher certaines attaques CSRF.