• [^] # Re: De la théorie à la pratique

    Posté par . En réponse à la dépêche Sortie d'Authentic 0.5. Évalué à 1.

    L'existence d'un module Apache ou d'un Reverse proxy pourrait effectivement aider. Car si on n'a rien en natif dans les serveurs d'applis ou dispositifs de portail par exemple, intégrer des systèmes variés sur un seul SSO Liberty Alliance ne doit pas être trivial.
    Si je comprends bien l'intérêt est d'avoir un maximum d'applications compatibles Liberty Alliance pour disposer d'un grand SSO global à ces applis. Simplement il faut minimiser le boulot pour les développeurs d'applications afin que celles-ci soient rendues compatibles avec Liberty Alliance.

    Soit on délègue la gestion de ses comptes à un module externe qu'on "libertifie" (par ex. un module Apache ou un reverse proxy), soit on se code à la mimine les appels aux quelques API de haut niveau fournies par exemple par LASSO. C'est bien çà ?

    Autre question que ça soulève (je bosse sur une application dont j'aimerais étudier la compatibilité avec un système Liberty Alliance, tout ceci m'a donné des idées !), quel est le rapport avec LemonLDAP dont on a déjà parlé ici ? Et existe-t-il un module Liberty Alliance pour LemonLDAP ? Je sais, c'est intéressé, mais moi je trouverais ça cool pour simplifier le portage d'applications existantes.

    Enfin, j'avais déjà regardé Liberty Alliance il y a un ou deux ans et je comprends de moins en moins le rapport avec SAML 2.0 ? Est-ce que Liberty Alliance (ID FF) est totalement compatible avec SAML ?
    En pratique vaut-il mieux faire du Liberty Alliance ou du SAML ?
    Ou alors SAML est un sous-ensemble de Liberty Alliance, (ou bien c'est le contraire, je suis dans le noir !) ?