CoreMedia Content Server Manual, Version 7.5.45-10
3.13.1. User Authentication | 3.13.1.2. License Management and Login Predicates

CoreMedia CMS license management is based on named licenses. With named licenses only a fixed and determined number of users can log on to the contentserver for a certain service. The following table lists the services and the associated types of CoreMedia applications.

When a user, no matter if built-in or LDAP user, logs on to the Content Server, he needs a named license for the desired service. The current named licenses in use are stored in a database. If a user logs on for the first time, the user name and the requested service are added to the database. If the maximum number of used named licenses for a service type is reached no further logins for users without named licenses are allowed. The authentication algorithm validates if the users listed in the license table still exist. If not, all used licenses for the non existing users are released and the user may log on. Otherwise, the login fails.

Example:

Assume that you have two licenses for the editor service. When user A is logged in on the Site Manager, user A consumes the first license. When a second user B logs on to the Site Manager he consumes the second and last free named license. Now no other user than A and B can log on to the editor, even if A or B or both log out again. The two named licenses for the Site Manager are reserved for user A and B, until A or B is deleted.

	Note
	Note: An administrator can manually query and remove used licenses from the database table. See the server tool cm usedlicenses in Section 3.14.2.17, “Usedlicenses”.

LoginPredicates

The login modules described in the previous section implement user authentication. So far a user may or may not log on to the contentserver whatever CoreMedia service he wants to use. The CapLoginModule and the LdapLoginModule can be configured to restrict user access to certain CoreMedia services. To do this, the two login modules use login predicates. A login predicate is a Java class which implements the interface LoginPredicate with the allowLogin() method. This method is invoked with a user and a CoreMedia service and returns a boolean value. A login module may use several login predicates. Login predicates are evaluated before user authentication in the login modules is actually performed and named licenses are consumed. The evaluation order for login predicates in a login module is as follows:

If no login predicate is specified in a login module, user authentication is performed against the login module.

If multiple login predicates are specified in a login module, they are evaluated in order of their index number <n>. If a login predicate for a user and service returns

The user fails to log on if all login predicates return null.

The login predicate Java classes are:

In the following these classes are described in detail.

NameLoginPredicate

This predicate returns true if the users name or the names of his groups match a regular expression, or null, if not:

AttributeLoginPredicate

This predicate returns true if the users LDAP attributes or the attributes of his groups match a regular expression or null if not.

JndiNameLoginPredicate

This predicate returns true if the users JNDI name or the JNDI names of his groups match a regular expression or null if not. The JNDI name is the LDAP distinguished name, that is the reference to the LDAP user entry:

TrueLoginPredicate

This predicate always returns true. It has no options but you must configure the predicate.<n>.args property with a space character; because JAAS complains if the space is missing.

Example:

A simplified jaas.conf file might use NameLoginPredicate and TrueLoginPredicate with CapLoginModule:

hox.corem.server.CapLoginModule sufficient

     /* System builtin users are not allowed to use the editor 
    service */ 
     predicate.1.class="hox.corem.login.NameLoginPredicate"
     predicate.1.args="negative=true,editor.regex=
    (serverdump|publisher|watchdog|workflow|
    webserver|importer)"

     /* All other users may login */
     predicate.2.class="hox.corem.login.TrueLoginPredicate"
     predicate.2.args=" "

The result of matching the regular expression (serverdump|publisher|watchdog|workflow|webserver|importer) is negated for users requesting the editor service. This means that the built-in users with the names serverdump, publisher, watchdog, workflow, webserver and importer are not allowed to use the editor. TrueLoginPredicate allows other users to start the editor and all users to use non-editor services.

Evaluation of login predicates is logged on the contentserver in the debug log level. If you want to see login predicate results switch the log level from info (default value) to debug and look for the word 'predicate' in the contentserver log after a user has tried to log on. You do not need to restart the contentserver when changing the log level.