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 :

  1. the field cn (or samAccountName) has to be used to find the user in the portal,
  2. 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.