Content Server Manual / Version 2406.1
Table Of ContentsCaution
CoreMedia Live Server Group management is not used anymore and has therefore been deprecated for many months.
CoreMedia is planning to remove Live Server Group management from the product portfolio with one of the upcoming releases.
CoreMedia CMS needs some groups and users for standard operation (so called built-in users/groups see Section 3.15.1, “Predefined Users and Groups”, for example publisher) on the Live Server. These groups and users are created when the server starts for the first time. In addition to these built-in groups you can add business oriented users and groups. With these groups you administrate access rights on the delivered content. You define the users who are allowed to read content.
Example:
You create a news site which offers standard content for registered customers, gold content for paying customers and platinum content for customers paying even more. The customers might sum up to 100.000. So you need to have at least 3 groups (such as standard, gold, platinum) on the Live Server containing 100.000 user.
It's as likely as not that your company administrates these users on an LDAP server. Therefore,
CoreMedia CMS supports any LDAP server. Because LDAP has no obvious
concept for content and live groups CoreMedia CMS provides
a UserProvider
class (see Section 3.12.3, “LdapUserProvider” and the Javadoc). This
class differentiates between live and content groups. CoreMedia provides the predefined
ActiveDirectoryUserProvider to connect to an Active Directory
server. If you use an Active Directory server you have the possibility to define all groups of this server as
Live Server groups, Content
Management Server groups or both using the properties
com.coremedia.ldap.contentgroups=true com.coremedia.ldap.livegroups=true
in the properties/corem/jndi.properties
file.
If you want to connect to another LDAP server you can extend the LdapUserProvider
class for your
own user provider (see Section 3.12.3, “LdapUserProvider” and the Javadoc).
You must not change the LdapUserProvider
after starting the content server with LDAP user
authentication. If, for example, you have defined content groups first, and change this to content and live
groups later, the live server will not notice this change.
Groups and users or memberships of groups and users are not published or replicated so you have to administrate them individually on each server. There is only one exception to this rule:
Assume, you have a resource with a rule connected to a group and this group does not exist on the Live Server. If you publish this resource, a group with the same name will be created on the Live Server. This group has no members and is no member of another group. It's only a placeholder so that the rule is connected to something, which you have to populate with memberships.
Groups need to be connected with rules in order to have impact. In the example above, the group platinum might
have a rule which allows members to read content contained in the platinum folder. For your convenience rules are
administrated on the Content Management Server and are
published and replicated. Therefore, the Content Management Server
needs to know the groups used on the Live Server. The easiest way to achieve
consistency between the two server types is to use the same LDAP server with the same UserProvider
configuration. You can also use different LDAP server but you have to ensure that the Live Groups on
Live Server and Content Management
Server are the same. Groups are identified by their name and domain so this has to be identical on
both servers.
If you have provided the Live Server groups to the Content Management Server, you can use the User Management App of the Studio to add rules to the groups. A rule will appear on the Live Server not until a resource connected to the rule has been published. To maintain data integrity only READ rights are allowed on the Live Server.