Authentication - SSO - MyLutece

Several APIs have been implemented from version 1.1 of Lutèce to manage security access to portal resources. The main implementation is made by the plugin MyLutece which realizes in a modular way the authentication and the management of the roles associated with the Authenticated users of the site. The purpose of this API is to provide an "SSO" (Single Sign On) provision, ie an authentication unique users shared by all applications. This means that any application of the portal will be able to verify that the current user is identified and to access its roles.

In addition to user authentication, these APIs allow the creation of role-based applications: private spaces, customization, preferences, application roles, ...

Authentication module API

Authentication management is modular and configurable, to support multiple implementations here is a non-exhaustive list:

• LDAP directory ( LDAPAuthentication )
• internal database ( BaseAuthentication )
• delegated authentication to the Web server (eg Tomcat)

All implementations must respect the interface fr.paris.lutece.portal.service.security.LutecePortalAuthentication .

There are two subsets of implementations:

• authentication is provided at Lutece level.
• authentication is carried out before Lutece (ex: web server or WSSO).

Authentication provided by Lutece following characteristics:

• it must provide methods of connection / disconnection ( login / logout ).
• it specializes the abstract class fr.paris.lutece.plugins.mylutece.authentication.PortalAuthentication .

Authentication based on an upstream system authentication will have characteristics following:

• it must not provide methods of connection / disconnection since these are provided by the device external located upstream.
• it specializes the abstract class fr.paris.lutece.plugins.mylutece.authentication.ExternalAuthentication .

User API and Account Management

Each authentication system can be associated with a user model that implements the minimal model defined by the interface fr.paris.lutece.portal.service.security.LuteceUser .

The planned implementations include:

• LDAPUser
• BaseUser

These implementations are not part of the kernel, they are available in the "mylutece" plugin under the package en.paris.lutece.plugins.mylutece.modules. *.

The way in which these user models deliver the user information is similar to the model proposed by the JSR 168 specification, based on itself on the Platform for Privacy Preferences 1.0 realized by the W3C. Thus the names and surnames are recovered from the keys user.given.name and user.given.family . The same attribute names are provided by the OASIS Web Services for Remote Portlets Technical Committee. See the list of attributes

Regarding the management of user accounts, several modes are possible:

• the user can not create an account himself. The creation of the account must then be carried out at of the directory either through an integrated administration function to Lutece either by a device other.

• the user can create an account without requiring the intervention of the administrators of the site. In this situation, the login screen will show a link to the page creating a new account.

In both situations, it will be possible for the identified user to access an optional and configurable page for viewing the account information. From this page and depending on the choice of account management it is possible to add functions for changing password or changing personal information.

Concerning the roles associated with the users, they correspond to the description made in the Java Servlet 2 specification, ie an abstract notion defined by an application which, associated with a user or group of users, makes it possible to define a security policy.

Important note : depending on the authentication system used, access to all roles is not always possible. For example, the web server-based authentication system only checks that a user has a given role through the isUserInRole method, but the list of other roles is not not available.

The new security service SecurityService

A new service has been added to the Lutece kernel to provide user management functions. This service is the entry point for all components: plugins, portlets, or applications that want to get the identity of the current user.

The main method to use is getRegisteredUser which allows to obtain the identity of the current user registered at the portal level.

A new UserNotSignedException exception has been added to the Content XPageApplication , to signify that the user must be authenticated to access the service or application. This exception is caught by the main page of the site, Portal.jsp . This saves the current parameters of the URL, redirects the user to the login page set in the mylutece.properties file. Once the identification is completed, the user is redirected to the url he was trying to access initially:

LuteceUser user = SecurityService.getInstance (). GetRegisteredUser (request);
     if (user! = null)
     {
           // The user is authenticated
           ...
     }
     else
     {
          // Throw an exception to force the user to login
          throw new UserNotSignedException ();
     }

Like the HttpServletRequest or PortletRequest (JSR 168) interfaces, SecurityService also provides the getRemoteUser , getUserPrincipal , and isUserInRole methods.

Implementation

---

Authentication setting: Installing the mylutece plugin

The plugin must be deployed like any plugin. If the authentication device uses the database proposed by default, you must install the lutece_users database, declare a connection pool to this database and associate this pool with the plugin in the plugins management interface.

Setting up the mylutece plugin

The parameters describing the chosen implementation are defined in the Lutece mylutece.properties configuration file using the properties following:

################################################## ######
# Authentication management
mylutece.authentication.enable = true
mylutece.authentication.class = fr.paris.lutece.portal.service.security.LDAPAuthentication

Description of the properties:

• lutece.authentication.enable : Determines whether the authentication mode of the Lutece instance will be based on SSO (required)
• lutece.authentication.class : Determines the class that implements the chosen authentication (to be completed if lutece.authentication.enable is true ).

The basic objects of the system

---

The default login screen

In the case of internal portal identification, the MyLutece plugin offers an identification page by default:

This page is accessible from http: myhost/lutece/jsp/site/Portal.jsp?Page=mylutece&action=login.

Its address and that of the processing of the identification form are set in the mylutece.properties file as follows:

mylutece.url.login.page=Portal.jsp?page=mylutece&action=login
         mylutece.url.doLogin=./plugins/mylutece/DoMyLuteceLogin.jsp

The identification portlet

The MyLutece plugin offers an identification portlet.

When the user is not logged in and the authentication system is Portal and not external, the portlet displays the login / password login form with optional links to an account creation or recovery page a forgotten password.

Once the user has been identified, the portlet displays a welcome message and the logout button.

The default pages for account management

The default pages for account management available in the MyLutece plugin are:

• create a new account
• display of personal information
• Forgot your password

The proposed implementations are not operational. If such account management functions are to be implemented, it will be necessary to carry out a XPageApp or JSPs to enable their implementation.

Functions such as changing the password or changing the personal information can be implemented in the same way and their access is to be expected at the level of the personal information display page.

The URLs for these functions are configured in the mylutece.properties file. The following example shows the configuration of an implementation performed with an XPageApp named account_manager :

mylutece.url.createAccount.page=Portal.jsp?page=account_manager&action=createAccount
    mylutece.url.viewAccount.page=Portal.jsp?page= account_manager&action=viewAccount
    mylutece.url.lostPassword.page=Portal.jsp?page= account_manager&action=lostPassword

Authentication control for applications

---

It is possible to submit all accesses to the portal to an authentication. In this case, no page or application is accessible to an unidentified user.

To implement this operating mode, the following property must be set to true in the file mylutece.properties :

# Only authenticated users can access the portal
    mylutece.portal.authentication.required = true

Authentication for applications

---

The XPageSecureApplication interface

Each application can, through the plugin in which it is packaged, define whether or not it requires authentication.

A new parameter is used in the plugin's XML definition file, by the application-security-model tag:

<application>
           <application-class>fr.paris.lutece.plugins.securedtest.SecuredTestApp</application-class>
           <application-security-model>1</application-security-model>
     </application>

The possible values ​​of this parameter are so far:

• 0: No authentication is required to access the application (the XPageApp version 1.0 works in this default template).
• 1: an authentication is required.

The XPageApps running in this model must implement the XPageSecureApplication interface.

If this parameter is not present for the plugin (case of plugins of v1.0), the default value is 0.

It is nevertheless possible to add the user management in the XPageApps implementing the old XPageSecureApplication base interface by explicitly calling SecurityService methods to obtain the identity of the user. 'user.

Application access management with roles

Another way, since Lutèce 1.3, limits access to the application only to users with an authorized role. This device is simpler and offers a finer management than the previous one.

To implement this restricted access, it is enough to define the authorized roles in the file of the plugin of the application as follows:

<application>
           <application-class>fr.paris.lutece.plugins.myplugin.MyApp</application-class>
           <application-Search>role1,role2,admin</application-Search>
     </application>

User management in the application

When connecting to a Lutece application, there is verification of the authentication mode of the application (or plugin).

• If the application does not require authentication, then the user has free access to the features of the application (currently the contact plugin).

• If in the plugin configuration file, it was defined that the application should be accessible only to an authorized population, then the actions following are undertaken:

• detection in the session of the authentication parameters.

• if the user is not yet authenticated, redirection to a Lutece-specific authentication page common to all applications.

• if the user is authenticated, and the application is not allowed for this user, redirection to an error page.

• If the user is authenticated and the application is authorized for this user, it is redirected to the application's home page.

The implementation of this mechanism is as follows:

In the case where the authentication device is internal:

Secure test application

---

A "securedtestapp" plugin has been created to test and illustrate the behavior of an application whose access is restricted. This application displays:

• the name of the authentication service used.
• the information available about the user.
• the roles possibly accessible to the user.

Summary and configuration memento

---

mylutece.authentication.enable = true mylutece.authentication.class = <authentication module class> |

In the XML file of the application plugin:

<Application-security-model>1</application-security-model>

In the XML file of the application plugin: <Application-Search> role1, role2, admin </application-Search> |

In the code of the application:

• Test if the user has the role for the given function with "isUserInRole ()"
• Force user authentication with "throw new UserNotSignedException ()" if it has not yet identified.