Chaining Lemonpdap::NG portals

Since version 0.9.4, Lemonldap::NG is able to delegate authentication to a remote portal. This can be use to share authentication without sharing session database to some handlers.

Principle

kinematic

remote-principle.png
  1. User tries to access to an application in the secondary Lemonldap::NG structure without having a session in this area
  2. Redirection to the portal of the secondary area (transparent)
  3. Redirection to the portal of the main area and normal authentication (if not done before)
  4. Redirection to the portal of the secondary area (transparent)
  5. Secondary portal check if remote session is available. It can be done via direct access to the session database or using SOAP access. Then it creates the session (with attribute filter)
  6. User can now access to the protected application
Note that if the user is already authenticated on the first portal, all redirections are transparents.

Configuration

Main Lemonldap::NG structure

Secondary Lemonldap::NG structure

Configure the portal to use the remote Lemonldap::NG structure. Example
my $p = Lemonldap::NG::Portal->new( {
  authentication             => 'Remote',
  userDB                     => 'Remote',
  remotePortal               => 'https://remote/',
  remoteGlobalStorage        => 'Lemonldap::NG::Common::Apache::Session::SOAP',
  remoteGlobalStorageOptions => {
    proxy => 'https://remote/index.pl/sessions',
    ns    => 'https://remote/Lemonldap/NG/Common/CGI/SOAPService',
  },
  # Optional: restrict exported attributes in the secondary area
  exportedAttr               => 'uid cn mail',
  ... as usual ...
});

Example : interoperability between 2 organizations

Using this, we can do a very simple interoperability system between 2 organizations using both Lemonldap::NG : So on each main portal, internal users can access normaly, and users issued from the other organization have just to click on the link :

remote-interoperability.png
  1. 1 user try to access to the portal
  2. external users click to be redirected to the remote type portal
  3. after redirection, normal authentication in the remote portal
  4. redirection to the remote type portal
  5. validation of the session : external user have now a local session