close

Filter

loading table of contents...

Content Server Manual / Version 2010

Table Of Contents

3.12.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.

Service Applications
debug Applications used for debugging like cm dump
editor Editor applications like Site Manager
importer CoreMedia Importer
publisher Publisher in contentserver
replicator Replicator in CoreMedia Replication Live Server
studioStudio Server, User Changes App
system System applications like cm documentcollector
webserverCAE, Elastic Worker
workflow CoreMedia Workflow Server
feeder Content Feeder, CAE Feeder

Table 3.7. CoreMedia services


When users, no matter if built-in or LDAP user, log on to the Content Server, they need 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

Note: An administrator can manually query and remove used licenses from the database table. See the server tool cm usedlicenses in Section 3.13.2.21, “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

  • false, then the user fails to log on immediately.

  • true, then user authentication is performed against the login module, unless a following login predicate fails.

  • null, then the result depends on the result of the other login predicates.

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

The login predicate Java classes are:

  • hox.corem.login.NameLoginPredicate

  • hox.corem.login.AttributeLoginPredicate

  • hox.corem.login.JndiNameLoginPredicate

  • hox.corem.login.TrueLoginPredicate

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:

NameLoginPredicate Options Description
negative Either 'true' or 'false' (default), if the Boolean value returned by the predicate is not null, then it is reversed. A true value is reversed to false and a false value is reversed to true.
depth

The NameLoginPredicate is not restricted to the user’s name but may also consider the names of the groups, he is member of. The integer value specifies the depth of group nesting (defaults to 0). '-1' means the nesting is unrestricted. The values are logically or-ed. If one of the values matches the regular expression, the predicate returns true.

For example, with depth=0 only the name of the user is used. With depth=1 the name of the user and the names of his direct groups are matched against the regular expression.

<service>.regex java.util.regex.Pattern regular expression value where <service> specifies a service name the pattern is mapped to. Only users matching the given service name and the given regular expression are allowed to log on. <service> must be one of "debug", "editor", "importer", "publisher", "replicator", "studio", "system", "webserver", "workflow", or "feeder".
regex

A java.util.regex.Pattern regular expression value which is mapped to all services, that means regex=some regular expression is an abbreviation for repeating the given expression for all possible services.

Table 3.8. NameLoginPredicate options


AttributeLoginPredicate

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

AttributeLoginPredicate Options Description
negative Same as for NameLoginPredicate
depth

The AttributeLoginPredicate is not restricted to the user’s attributes but may also consider the attributes of the groups, he is member of. The integer value specifies the depth of group nesting (defaults to 0). '-1' means the nesting is unrestricted. The attributes are the strings returned by the method call hox.corem.usermanager.User#getAttributeKeys(). For the LDAP server, these are the values configured with the properties cap.server.userproviders[#].ldap.user.custom-attributes for a user and cap.server.userproviders[#].ldap.group.custom-attributes for a group in the contentserver application properties. The values are logically or-ed. If one of the values matches the regular expression, the predicate returns true.

For example, with depth=0 only the LDAP attributes of the user are used. With depth=1 the LDAP attributes of the user and the LDAP attributes of his direct groups are matched against the regular expression.

<service>.regex Same as for NameLoginPredicate
regex Same as for NameLoginPredicate

Table 3.9. AttributeLoginPredicate options


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:

JndiNameLoginPredicate Options

Description

negative

Same as for NameLoginPredicate

depth

The JndiNameLoginPredicate is not restricted to the user’s JNDI name but may also consider the JNDI names of the groups, he is member of. The integer value specifies the depth of group nesting (defaults to 0). '-1' means the nesting is unrestricted. The values are logically or-ed. If one of the values matches the regular expression, the predicate returns true.

For example, with depth=0 only the JNDI name of the user is used. With depth=1 the JNDI names of the user and the JNDI names of his direct groups are matched against the regular expression.

<service>.regex

Same as for NameLoginPredicate

regex

Same as for NameLoginPredicate

Table 3.10. JndiNameLoginPredicate options


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=
    (publisher|studio|watchdog|workflow|
    webserver|importer)"

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

Example 3.10. jaas.conf example


The result of matching the regular expression (publisher|studio|watchdog|workflow|webserver|importer) is negated for users requesting the editor service. This means that the built-in users with the names publisher, studio, 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 Content Server 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 Content Server log after a user has tried to log on. You do not need to restart the Content Server when changing the log level.

Search Results

Table Of Contents