Access Control

When using the Ceptor Management GUI, Ceptor management API and Ceptor Admin client is protected by a mini user access system.

The access control is handled through the security configuration in the ceptor-configuration.xml which points to an access.controller which can be either a pure XML based implementation or an LDAP based implementation.

The default configuration of Ceptor comes with the XML based configuration setup - and looks like shown below.


<group name="security" description="security configuration">
	<property name="access.control.configuration" value="${ceptor.home}/config/ceptor-security.xml" description="access control definitions"/>
	<property name="access.controller" value="dk.itp.security.accesscontrol.AccessControlListXMLImpl" description="config server access controller implementation"/>
	<property name="remote.servers" value="localhost,192.168.255.255,10.255.255.255" description="allowed remote servers, host:port separated by ,;"/>
</group>


Common for the XML file implementation and the LDAP implementation is the ACL definitions which ensures access to the different part of the Ceptor administration. 

Basically the access system is based on Java's security model: User-group-acl-permission - as shown below.


In the XML file implementation all information is stored in an XML file. In the LDAP implementation only ACL's and permissions are stored in an XML file, the users and groups are found in LDAP.

File-Based Access Control

File based access control us done using the AccessControllerListXMLImpl access.controller configuration property. See default example above.

The configuration file given in access.control.configuration must contain users, groups and acls. 

An example can be found in the default installation directory; <CEPTOR_HOME>/config/ceptor-security.xml, where <CEPTOR_HOME> is the directory which Ceptor is installed in.


Create Groups and Users Using Ceptor Console

You can use the Ceptor Console to administer groups and users; Select "Security Configuration" from the menu, and you get this screen.


Here, you can manage groups and users, or you can select the Access Management tab and administer ACLs and decide which ACLs require which groups.

Any changes you make using the console gets replicated to all configuration servers in a cluster so they all get updated with the new information.

Create a User Using Command Line

A new user is created by running java dk.itp.security.Passwd. This command takes two arguments: user id and password.
Output from the command is a line which is pasted into ${ceptor.home}/config/ceptor-security.xml

For example.:

C:\Program Files\Ceptor>jre\bin\java -classpath lib\PortalProtectServer.jar;lib\PortalProtectAgent.jar;extlib\bcprov-jdk16-145.jar dk.itp.security.Passwd test password
PortalProtect Security AA file entry generator
Generates user entries for use in the ceptor-security.xml configuration file
<user userid="test" password="%7BSSHA%7DEUWFrNL9hc%2F2DyB0AG0IiyFMMwN6OgNVC3daoOCBjc0%3D" />

Here a user with userid test and with password password. The last line in the example, is the one to be copied into  ${ceptor.home}/config/ceptor-security.xml.

Afterwards, Ceptor needs to be restarted as the file is only read under startup.

For example:

Now the user is defined. Now rights need to be established.

Rights can be given to a user in different ways:

  1. A user can be associated with a group where rights are defined.
  2. The user can have rights defined directly.

Change Password

If the password of a user needs to be changed, the same utility as described in the previous chapter is to be used, or the users password can be changed in the Ceptor Console.

Add a User to a Group

A user can be added to a group by adding the users is to the group, for example:

The user is now a member of the group admin and will have rights as defined on the admin group and on the user himself.
A users membership of a group is removed by removing the <member> section from the group.

Create a new Group

A new user group is created by adding a <group> section to ${ceptor.home}/config/ceptor-security.xml.

In the above example, a group is defined but it has no members.

Create the Rights on an ACL

The rights for a group and a user are created by updating the specific ACL:

In the above example a testusers group is added to an acl with the name web.* and with the right read.

An <acl> definition supports wildcard. The acl web.somethings.othertings.stuff can be replaced by the definition of web.*. If both are used the rights are investigated by investigating access furthest down the acl tree. That is, if web.somethings.othertings.stuff har a read right and web.* has read/write and the calling function is web.somethings.othertings.stuff, the access will be restricted to read access.

The example above means ”the users who are members of the group test users all have rights to all acls which are controlled by web.*, or in practice all web GUIs.

Update Rights on an ACL

In this chapter a list of rights is shown which can be used to define a user or a group’s access control to the old PortalProtect/Ceptor HTML web manage UI and the new Ceptor management GUI.

An acl is built up of the following elements.

<system>.<subsystem>.<function>

In the old HTML web UI implementation only one system is supported: web. Ceptor supports also “telnet” but as the built-in telnet server is a prototype implementation, this is not supported. The picture below shows all the ACL's that are checked in that UI.


In the new Ceptor web management GUI all management are based on the existing administration API also described here Administration API (and also accessible through the administration REST services described here Admin REST Service). The ACLs in use for these interfaces are shown in the image below - here only the system "ppadmin" is used.


The ACL's are used in the ceptor-security.xml file, and can be configured like this:

web.configuration-management.manage is the acl name on that right which manages the displaying and updating of the configuration. If one adds the test user group and a relevant right:

Then the users who are members of the testusers group only have the right to read and not update the configuration.


Extending or Changing the User Model

Ceptor contains a plug in security architecture for authenticating users which require access to the console – it is possible to plug in other user repositories, such as Active Directory by implementing the interface dk.itp.security.accesscontrol.IAccessControl and configuring the class which contains the new plug in in the property access.controller in the configuration for the configuration servers. Please contact support for more information if you need to change this.

© Ceptor ApS. All Rights Reserved.