LemonLDAP::NG Frequently Asked
Questions
General
questions
What is a Web-SSO
?
A SSO
(Single Sign On) is a
system that is used to share authentications between many applications.
User logs in only one time and is never prompted when he tries to access
to another application. Kerberos (used in Active Directory) for example is
an SSO mechanism. The problem with these systems is that in addition to
their heaviness, they apply only to internal networks and to relatively
homogeneous machines.
The Web-SSO is the bearing of this principle
restricted with the Web applications. The user is thus authenticated with
the first access to a protected Web application and the authentications
are propagated when it changes application. The large advantage is whereas
the system is usable on Internet without pre-necessary on the stations
customers (they just have to accept session cookies). For example, when a
user reaches a Google letter-box, it is not authenticated if it reaches
the groups management application or any other Google application.
What brings
LemonLDAP::NG compared to the other Web-SSO ?
- LemonLDAP::NG run as Perl Apache modules and offer performances
which make imperceivable the treatment of the access control.
- One of the other strong points of LemonLDAP::NG is its capacity to
manage the rights in a centralized way: the standard SSO Kerberos or
CASE allow authentication share but delegate management access
authorizations to the applications. In the case of LemonLDAP::NG,
management rights can be centralized completely, partly or at all for
each application: LemonLDAP::NG provides a system of authorization based
on the sorting of the URL by regular expressions associated to rules. It
also provides HTTP headers containing any of the user attributes to the
remote application. The remote application can then manage the
traceability of the access and possibly authorization.
- LemonLDAP::NG can publish every user attributes or calculate
expressions issued from them. So applications can avoid consulting LDAP
or database server.
- LemonLDAP::NG treats all the hosted sites independently (virtual or
real): every application can so have its personalized HTTP headers.
- LemonLDAP::NG provide an web based administration interface simply
presenting the configuration, the access policy and the per sites
headers.
Is it really
free?
Yes, LemonLDAP::NG is released under GPL license
(see
here).
Configuration
Where is
the configuration?
LemonLDAP::NG stores its configuration in a
global storage. See available backends
here.
You can also manage local parameters by editing
lemonldap-ng.ini file.
The provided example
works with HTTP, but not with HTTPS.
In the redirection mechanism to the portal then
to the protected site, you have to indicate to the handler if users access
by HTTPS or HTTP to it. This is done by the
https parameter. You
can also edit
port to force port in redirections.
What is
an auto-protected CGI?
When you have just one Perl CGI to protect in a
VirtualHost, you can use an auto-protected CGI instead of using a
LemonLDAP::NG handler:
use Lemonldap::NG::Handler::CGI;
my $cgi = Lemonldap::NG::Handler::CGI->new ( {
# same parameters than a Lemonldap::NG::Handler::SharedConf handler
}
);
$cgi->authenticate;
In the example above, $cgi is a CGI(3) object.
The only difference is that it has some additional functions:
- authenticate: to call LemonLDAP::NG authentication mechanism,
- authorize: use it if you want to use the manager to manage the
access policy,
- user: returns an hash table containing user parameters,
- group: used to validate group membership.
This type of CGI is very usefull when rights can not be distinguish
by URL (fields in POST requests for example). See the
Lemonldap::NG::Handler::CGI(3) man page for more.
How to use LemonLDAP::NG
with Active-Directory ?
Active-Directory uses
sAMAccountName
field instead of
uid as unique identifier.
You have so to modify LemonLDAP::NG
configuration:
- Modify LDAP authentication filter (Auth LDAP)
- Add sAMAccountName to exported attributes
- Set whatToTrace parameter to $samAccountName.
How to use LemonLDAP::NG as
reverse-proxy ?
LemonLDAP::NG protects Apache VirtualHosts. To
use it as reverse-proxy, you just have to configure Apache as
reverse-proxy:
# httpd.conf
<VirtualHost>
ServerName MyApplication.com
PerlRequire MyFile
PerlHeaderParserHandler My::Package
ProxyPass / http://real-server/
ProxyPassReverse / http://real-server/
</VirtualHost>
If you prefer to use a Perl proxy, LemonLDAP::NG
provides one (Lemonldap::NG::Handler::Proxy(3))
Operation
What is
Handler local cache?
The handler local cache is used for 2 things:
- share configuration between Apache process: this avoid downloading
configuration for each new process. This is required for the reload
mechanism system that avoid restarting Apache,
- share sessions between Apache process and threads: this avoid having
to request the central sessions storage for each hit. For example with
Apache::Session::MySQL, we transform TCP requests in file system
requests. This increase performances.
Why handlers
local cache can not be configured by the Manager?
The local cache has to be choosen and configured
for each server: for example with the
Cache::FileCache module,
the storage directory can be different. An other point is that the local
storage can not be reloaded without restarting Apache, but all parameters
managed by the manager can do it.
How works the
Cross Domain Authentication (CDA) ?
The LemonLDAP::NG sessions propagation system is
based on cookies, but cookies are attached to a DNS domain. LemonLDAP::NG
provides a system to bypass this restriction.
Lemonldap::NG portal detects if required URL is
in the same domain. If not, it adds a parameter to this request. When the
user returns to the protected application, Lemonldap::NG Handler detects
this parameter et generate a cookie in its domain.
What
is "notification system"?
It's a system used to notify a message to a user
using the portal. If the message contains checkboxes, they have to be all
checked to open the session.
Error and debug
messages
LemonLDAP::NG produces error and debug messages
logged by Apache (in error.log by default). You can adapt debug level by
setting LogLevel parameter in Apache configuration file.
Those messages are described
here.