Configuration can be stored in several formats (<ahref="sqlconfbackend.html"class="wikilink1"title="documentation:2.0:sqlconfbackend">SQL</a>, <ahref="fileconfbackend.html"class="wikilink1"title="documentation:2.0:fileconfbackend">File</a>, <ahref="ldapconfbackend.html"class="wikilink1"title="documentation:2.0:ldapconfbackend">LDAP</a>) but must be shared over the network if you use more than 1 server. If some of your servers are not in the same (secured) network than the database, it is recommended to use <ahref="soapconfbackend.html"class="wikilink1"title="documentation:2.0:soapconfbackend">SOAP access</a> for those servers.
</p>
<divclass="notetip">You can use different type of access: <ahref="sqlconfbackend.html"class="wikilink1"title="documentation:2.0:sqlconfbackend">SQL</a>, <ahref="fileconfbackend.html"class="wikilink1"title="documentation:2.0:fileconfbackend">File</a> or <ahref="ldapconfbackend.html"class="wikilink1"title="documentation:2.0:ldapconfbackend">LDAP</a> for servers in secured network and <ahref="soapconfbackend.html"class="wikilink1"title="documentation:2.0:soapconfbackend">SOAP</a> for remote servers.
</div>
<p>
Next, you have to configure the SOAP access as described <ahref="soapconfbackend.html#next_configure_soap_for_your_remote_servers"class="wikilink1"title="documentation:2.0:soapconfbackend">here</a> since SOAP access is denied by default.
<h2class="sectionedit3"id="protect_the_manager">Protect the Manager</h2>
<divclass="level2">
<p>
By default, the manager is restricted to the user 'dwho' (default backend is Demo). To protect the manager, you have to choose one or both of :
</p>
<ul>
<liclass="level1"><divclass="li"> protect the manager by Apache configuration</div>
</li>
<liclass="level1"><divclass="li"> protect the manager by <abbrtitle="LemonLDAP::NG">LL::NG</abbr></div>
</li>
</ul>
</div>
<!-- EDIT3 SECTION "Protect the Manager" [810-1069] -->
<h3class="sectionedit5"id="protect_the_manager_by_llng">Protect the Manager by LL::NG</h3>
<divclass="level3">
<p>
To protect the manager by <abbrtitle="LemonLDAP::NG">LL::NG</abbr>, you just have to set this in <code>lemonldap-ng.ini</code> configuration file (section [manager]):
<divclass="noteimportant">Before, you have to create the virtual host <code>manager.your.domain</code> in the manager and set a <ahref="writingrulesand_headers.html#rules"class="wikilink1"title="documentation:2.0:writingrulesand_headers">rules</a>, else access to the manager will be denied.
<liclass="level1"><divclass="li"><ahref="https://en.wikipedia.org/wiki/Cross-site_request_forgery"class="urlextern"title="https://en.wikipedia.org/wiki/Cross-site_request_forgery"rel="nofollow">CSRF</a> protection <em>(Cross-Site Request Forgery)</em>: a token is build for each form. To disable it, set requireToken to 0 <em>(portal security parameters in the manager)</em>. Token timeout can be defined via manager (default to 120 seconds),</div>
</li>
<liclass="level1"><divclass="li"><ahref="https://en.wikipedia.org/wiki/Content_Security_Policy"class="urlextern"title="https://en.wikipedia.org/wiki/Content_Security_Policy"rel="nofollow">Content-Security-Policy</a> header: portal build dynamically this header. You can modify default values in the manager <em>(Général parameters » Advanced parameters » Security » Content-Security-Policy)</em>.</div>
<liclass="level1"><divclass="li"><ahref="https://en.wikipedia.org/wiki/Brute-force_attack"class="urlextern"title="https://en.wikipedia.org/wiki/Brute-force_attack"rel="nofollow">Brute-force attack</a> protection: after some failed logins, user must wait before re-try to log into Portal.</div>
<divclass="noteimportant">* Brute-force attack protection is DISABLED by default
<p>
* Browser implementations of form Action directive are inconsistent (e.g. Firefox doesn't block the redirects whereas Chrome does). Administrators may have to modify form Action value with wildcard likes *.
<h3class="sectionedit7"id="split_portal_when_using_soaprest">Split portal when using SOAP/REST</h3>
<divclass="level3">
<p>
If you use <ahref="soapsessionbackend.html"class="wikilink1"title="documentation:2.0:soapsessionbackend">SOAP</a> or <ahref="restsessionbackend.html"class="wikilink1"title="documentation:2.0:restsessionbackend">REST</a> session backend, dedicate a portal especially for these internal requests.
<ahref="writingrulesand_headers.html#rules"class="wikilink1"title="documentation:2.0:writingrulesand_headers">Rules</a> are applied in alphabetical order (comment and regular expression). The first matching rule is applied.
You can write <ahref="writingrulesand_headers.html#rules"class="wikilink1"title="documentation:2.0:writingrulesand_headers">rules</a> matching any component of <abbrtitle="Uniform Resource Locator">URL</abbr> to protect including GET parameters, but be careful.
</p>
<p>
For example with this rule on the <code>access</code> parameter:
Some characters are encoded in URLs by the browser (such as space,…). To avoid problems, <abbrtitle="LemonLDAP::NG">LL::NG</abbr> decode them using <ahref="https://metacpan.org/pod/Apache2::URI#unescape_url"class="urlextern"title="https://metacpan.org/pod/Apache2::URI#unescape_url"rel="nofollow">https://metacpan.org/pod/Apache2::URI#unescape_url</a>. So write your rules using normal characters.
See <ahref="http://httpd.apache.org/docs/2.2/mod/mod_proxy.html"class="urlextern"title="http://httpd.apache.org/docs/2.2/mod/mod_proxy.html"rel="nofollow">mod_proxy</a> and <ahref="http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html"class="urlextern"title="http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html"rel="nofollow">mod_rewrite</a> documentation for more about configuring Apache reverse-proxies.
</p>
<p>
Such configuration can have some security problems:
</p>
<ul>
<liclass="level1"><divclass="li"> if a user can access directly to the hidden application, it can bypass <abbrtitle="LemonLDAP::NG">LL::NG</abbr> protection</div>
</li>
<liclass="level1"><divclass="li"> if many hidden applications are on the same private network, if one is corrupted (by SQL injection, or another attack), the hacker will be able to access to other applications without using reverse-proxies so it can bypass <abbrtitle="LemonLDAP::NG">LL::NG</abbr> protection</div>
</li>
</ul>
<p>
It is recommended to secure the channel between reverse-proxies and application to be sure that only request coming from the <abbrtitle="LemonLDAP::NG">LL::NG</abbr> protected reverse-proxies are allowed. You can use one or a combination of:
</p>
<ul>
<liclass="level1"><divclass="li"> firewalls (but be careful if more than 1 server is behind the firewall)</div>
</li>
<liclass="level1"><divclass="li"> server based restriction (like Apache “allow/deny” mechanism)</div>
</li>
<liclass="level1"><divclass="li"> SSL client certificate for the reverse-proxy (see SSLProxy* parameters in <ahref="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html"class="urlextern"title="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html"rel="nofollow">mod_ssl documentation</a>)</div>
<liclass="level1"><divclass="li"><strong>Force authentication</strong>: set to 'On' to force authentication when user connects to portal, even if he has a valid session.</div>
<liclass="level1"><divclass="li"><strong>Force authentication interval</strong>: time interval (in seconds) when a authentication renewal cannot be forced, used to prevent to loose the current authentication during the main process. If you experience slow network performances, you can increase this value.</div>
</li>
<liclass="level1"><divclass="li"><strong>Encryption key</strong>: key used to crypt some data, should not be known by other applications</div>
</li>
<liclass="level1"><divclass="li"><strong>Trusted domains</strong>: domains on which the user can be redirected after login on portal. Set '*' to accept all.</div>
</li>
<liclass="level1"><divclass="li"><strong>Use Safe jail</strong>: set to 'Off' to disable Safe jail. Safe module is used to eval expressions in headers, rules, etc. Disabling it can lead to security issues.</div>
</li>
<liclass="level1"><divclass="li"><strong>Check <abbrtitle="Cross Site Scripting">XSS</abbr> Attacks</strong>: Set to 'Off' to disable <abbrtitle="Cross Site Scripting">XSS</abbr> checks. <abbrtitle="Cross Site Scripting">XSS</abbr> checks will still be done with warning in logs, but this will not prevent the process to continue.</div>
<liclass="level1"><divclass="li"><strong>Brute-Force Attack protection</strong>: set to 'On' to enable it. The aim of a brute force attack is to gain access to user accounts by repeatedly trying to guess the password of a user. If it is disabled, automated tools may submit thousands of password attempts in a matter of seconds, making it easy for an attacker to beat a password-based authentication system.</div>
<liclass="level1"><divclass="li"><strong>LWP::UserAgent SSL options</strong>: insert here options to pass to LWP::UserAgent object (used by <abbrtitle="Security Assertion Markup Language">SAML</abbr> or OpenID-Connect to query partners). Example: <code>verify_hostname ⇒ 0</code>, <code>SSL_verify_mode ⇒ 0</code></div>
You can change the module used for sessions identifier generation. To do, add <code>generateModule</code> key in the configured session backend options.