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.
Users authentify themself only one time and is never prompted when he
tries to access to another application. Kerberos (used in Active
Directory) for example is a SSO. 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 authentifications
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 authentified if it reaches the
groups management application or any other Google application.
What brings
Lemonldap::NG compared to the other Web-SSO ?
- Lemonldap::NG like lemonldap run as Perl Apache modules and offer
performances which make unperceivable 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 LDAP
atributes to the remote application. The remote application can then
manage the traceability of the access and possibly authorization (see to
it
documentation AAA).
- Lemonldap::NG can publish every LDAP attributes or calculated
expressions issued from them. So applications can avoid consulting LDAP
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 (see the demonstration).
A restricted interface can also be used to show only some virtual hosts
(for reading and/or writing): the interface of administration can thus
be partially delegated.
Configuration
What type of configuration
storage has to be used ?
Lemonldap::NG provides 3 configuration storage
systems:
- File: the most simple system, it can
be used only if all your servers share a file system. It can be used for
example if all virtual hosts are on the same server,
- DBI: DBI(3) is a
database access module for the Perl programming language. Used with
Lemonldap::NG, it permits to share configuration between servers that
can access to the same database. This is the recommended sheme on a
server network.
- SOAP: This system is not a real
storage system, but permits to a remote server to access to the
configuration by a single HTTP(S) connection. The SOAP server use File
or DBI to access to the real configuration and act as a proxy.
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. This
parameter has to be configured directly in the handlers is not accessible
by the manager interface:
__PACKAGE__->init ( {
localStorage => "Cache::FileCache",
localStorageOptions => {
'namespace' => 'MyNamespace',
'default_expires_in' => 600,
'directory_umask' => '007',
'cache_root' => '/tmp',
'cache_depth' => 5,
},
configStorage => {
type => 'File',
dirName => '/var/lib/lemonldap-ng/conf',
},
https => 1,
} );
For what is used the "https"
parameter ?
This parameter is used only in authentication
portal redirections. It is just used to indicate to the portal that after
authentification, the user must be redirected towards the application
using https and not http.
What is
an auto-protected CGI ?
When you have just 1 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,
- autorize : 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 permet de valider 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
cn field instead
of
uid as unique identifier. You have so to modify Lemonldap::NG
configuration in 2 points :
- the field cn (or samAccountName) has to be used to
find the user in the portal,
- Apache has to use this field in logs.
For the second point, you have to replace
$uid by
$cn in the field "General Parameters -> Attribute to use in
Apache's logs" (and to verify that this variable is an exported
attribute). The LDAP filter change needs to overload a subroutine in the
portail. This can be done so :
#!/usr/bin/perl
use Lemonldap::NG::Portal::SharedConf;
my $portal = Lemonldap::NG::Portal::SharedConf->new(
{
configStorage => {
type => 'File',
dirName => '/var/lib/lemonldap-ng/conf',
},
formateFilter => sub {
my $self = shift;
$self->{filter} = "(&(cn=" . $self->{user} . ")(objectClass=person))";
PE_OK;
} # end of overload
}
);
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/
# You can also use mod_rewrite instead of mod_proxy
# RewriteEngine On
# RewriteRule /(.*)$ http://serveur-reel/$1 [P]
</VirtualHost>
If you prefer to use a Perl proxy, Lemonldap::NG
provides one (Lemonldap::NG::Handler::Proxy(3))
Operation
With what serves the 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 choosed nad 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.
What is 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: you just have to use a
Lemonldap::NG::Portal::CDA portal and Lemonldap::NG::Handler::CDA handlers
in all protected sites outwards the portal DNS domain.
How works the
Cross Domain Authentication (CDA) ?
Lemonldap::NG::Portal::CDA 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::CDA agent detects this parameter et generate a
cookie in its domain.
Authentication
How to change authentication scheme
?
Lemonldap::NG provides several authentication
modes (to use in the "authentification" field of the administration
interface) :
- ldap : this is the default mode :
portal tries to connect to the LDAP server with the user
credentials,
- CAS : Lemonldap::NG portal becomes a
simple CAS proxy : if the user is not authenticated, it is redirected to
the CAS portal,
- SSL : in this scheme, authentication
is done by Apache by SSL. This is usefull to replace complete SSL
protection: only one SSL negociation is used instead,
- Apache : in this scheme,
authentication is done by Apache. For example with Kerberos, the Apache
Kerberos module protects only the portal. This increases performances
because only one Kerberos negociation has to be done for all protected
applications.
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.