<h3class="sectionedit7"id="configuration_of_lemonldapng">Configuration of LemonLDAP::NG</h3>
<divclass="level3">
<p>
...
...
@@ -192,13 +224,11 @@ Then, go in <code>SSL parameters</code>:
</li>
<liclass="level1"><divclass="li"><strong>Extracted certificate field</strong>: field of the certificate affected to $user internal variable</div>
</li>
<liclass="level1"><divclass="li"><strong>Conditional extracted certificate field</strong>: field of the certificate affected to $user internal variable depending on the certificate authority. Key is the CA <abbrtitle="Distinguished Name">DN</abbr>, value is the field.</div>
</li>
</ul>
</div>
<!-- EDIT8 SECTION "Configuration of LemonLDAP::NG" [2369-2982] -->
<divclass="notewarning">It is incompatible with authentication chaining (see Stack Multiple backends), because of Apache parameter “SSLVerifyClient”, which must have the value “require”
<divclass="notewarning">It is incompatible with authentication combination because of Apache parameter “SSLVerifyClient”, which must have the value “require”
<ahref="server_to_server.0fea6a13c52b4d4725368f24b045ca84.png"title="View original file"><imgwidth="867"height="542"class="img_detail"alt="server_to_server.png"title="server_to_server.png"src="server_to_server.5462faf15ddb078d04b190542596d5c2.png"/></a>
<ahref="servertoserver.html"class="action img_backto"accesskey="b"rel="nofollow"title="Back to documentation:2.0:servertoserver [B]">Back to documentation:2.0:servertoserver</a></div>
<h1class="sectionedit1"id="handling_server_webservice_calls">Handling server webservice calls</h1>
<divclass="level1">
<p>
In modern applications, web application may need to call some other web application on behalf of the connected users. There is three way to do it: the ugly and the smart.
</p>
<p>
The ugly consists to give the cookie value to the webapp 1 which use it in cookie header of its request. Since version 2.0, LLNG gives a better way to do it using tokens with limited scope.
Webapp1 can read this header and use it in its requests in the <code>X-Llng-Token</code> header. The token is build using the session ID and the list of authorized virtualhosts. The token is available only 30 and only the listed virtualhosts.
Change handler type to “ServiceToken”. So it is able to manage both user and server connections. And that's all !
</p>
<divclass="noteimportant">If you use “Server” platform (Nginx), don't forget to give the <code>X-Llng-Token</code> header to the FastCGI handler (formatted as <code>HTTP_X_LLNG_TOKEN</code>).
<liclass="level1"><divclass="li"><ahref="servertoserver.html"class="wikilink1"title="documentation:2.0:servertoserver">Handling server webservice calls</a></div>
<seg>Dans Debian/Ubuntu mod_ssl est installé avec le paquet apache2.2-common.</seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>As you may have guessed, these accounts are famous characters from the TV show Doctor Who.</seg>
...
...
@@ -31756,14 +31748,6 @@ Le nouveau rôle doit-il être autorisé à créer de nouveaux rôles ?</seg>
<seg>error : si l'utilisateur n'a pas accès, une erreur est affichée sur le portail, l'utilisateur n'est pas redirigé vers le service CAS</seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>It is incompatible with authentication chaining (see Stack Multiple backends), because of Apache parameter “SSLVerifyClient”, which must have the value “require”</seg>
<seg>Ce n'est pas compatible avec une chaîne d'authentification (voir Empiler plusieurs backends), en raison du paramètre Apache “SSLVerifyClient”, qui doit être mis à la valeur “require”</seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>See also general kinematics presentation.</seg>
<seg>Dans Debian/Ubuntu mod_ssl est installé avec le paquet <bpt i='0' x='0'><c0></bpt>apache2.2-common<ept i='0'></c0></ept>.</seg>
</tuv>
</tu>
<tu>
<tuv xml:lang="EN-US">
<seg>As you may have guessed, these accounts are famous characters from the TV show <bpt i='0' x='0'><a0></bpt>Doctor Who<ept i='0'></a0></ept>.</seg>
...
...
@@ -31756,14 +31748,6 @@ Le nouveau rôle doit-il être autorisé à créer de nouveaux rôles ?</seg>
<seg><bpt i='0' x='0'><s0></bpt>error<ept i='0'></s0></ept> : si l'utilisateur n'a pas accès, une erreur est affichée sur le portail, l'utilisateur n'est pas redirigé vers le service <bpt i='1' x='1'><a1></bpt>CAS<ept i='1'></a1></ept></seg>
</tuv>
</tu>
<tu>
<tuv xml:lang="EN-US">
<seg>It is incompatible with authentication chaining (see Stack Multiple backends), because of Apache parameter “SSLVerifyClient”, which must have the value “require”</seg>
<seg>Ce n'est pas compatible avec une chaîne d'authentification (voir Empiler plusieurs backends), en raison du paramètre Apache “SSLVerifyClient”, qui doit être mis à la valeur “require”</seg>
</tuv>
</tu>
<tu>
<tuv xml:lang="EN-US">
<seg>See also <bpt i='0' x='0'><a0></bpt>general kinematics presentation<ept i='0'></a0></ept>.</seg>
<seg>Dans Debian/Ubuntu mod_ssl est installé avec le paquet <c0>apache2.2-common</c0>.</seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>As you may have guessed, these accounts are famous characters from the TV show <a0>Doctor Who</a0>.</seg>
...
...
@@ -31756,14 +31748,6 @@ Le nouveau rôle doit-il être autorisé à créer de nouveaux rôles ?</seg>
<seg><s0>error</s0> : si l'utilisateur n'a pas accès, une erreur est affichée sur le portail, l'utilisateur n'est pas redirigé vers le service <a1>CAS</a1></seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>It is incompatible with authentication chaining (see Stack Multiple backends), because of Apache parameter “SSLVerifyClient”, which must have the value “require”</seg>
<seg>Ce n'est pas compatible avec une chaîne d'authentification (voir Empiler plusieurs backends), en raison du paramètre Apache “SSLVerifyClient”, qui doit être mis à la valeur “require”</seg>
</tuv>
</tu>
<tu>
<tuv lang="EN-US">
<seg>See also <a0>general kinematics presentation</a0>.</seg>
