Configuring Arbortext Publishing Engine > Configuring Arbortext Editor to Use Arbortext PE server > Arbortext Publishing Engine Security Framework > Configuring Security Constraints
  
Configuring Security Constraints
Security constraints are the mechanism used by the Arbortext PE Request Manager to classify a request as disabled, unrestricted, or restricted. Each security constraint consists of one or two parameters and a test set. When the Arbortext PE Request Manager receives a request, it searches the list of security constraints defined in e3config.xml until it finds a security constraint with a test set matching the request. The search is in the order security constraints are configured in e3config.xml. If no security constraint matches the request, the Arbortext PE Request Manager rejects the request with an error message.
If a security constraint’s access parameter value is restricted, the Arbortext PE Request Manager checks to see if the request is authenticated. If not, the Arbortext PE Request Manager rejects the request using an HTTP result code that states authentication is required. Most web browsers will prompt for an ID and password and resubmit the request. If the password is legal for the ID, the resubmitted request will be considered properly authenticated. If the request is authenticated, it will have an associated user ID and the Arbortext PE Request Manager will check to see whether the user ID has the role specified by the security constraint's role parameter value. If the ID has the role specified, the request is allowed to proceed. If the role does not, the Arbortext PE Request Manager rejects the request with an error message.
Following is a sample security constraint configuration as delivered in e3config.xml.  Note that the security constraint named “admin-requests” refers to the standalone test set “admin-tests” using the ref attribute, while security constraint named “unrestricted-requests” has an in-context  test set.
<!-- Security Constraints that determine who can submit which
requests. Note that users and roles are defined in web.xml
and in Tomcat's tomcat-users.xml configuration files.
-->
<SecurityConstraints>
<!-- The following requests must be submitted by an
authenticated user with the "pe-admin" role. -->
<SecurityConstraint id="admin-requests">
<Parameter name="access" value="restricted"/>
<Parameter name="role" value="pe-admin"/>
<TestSet ref="admin-tests"/>
</SecurityConstraint>
<!-- The following requests may be submitted by any user.
No authentication is required. -->
<SecurityConstraint id="unrestricted-requests">
<Parameter name="access" value="unrestricted"/>
<TestSet>
<Or>
<Test name="test-request-unrestricted"/>
<Test name="test-editor-queuing"/>
</Or>
</TestSet>
</SecurityConstraint>
</SecurityConstraints>
Creating security constraints can become fairly complex, and it is possible to code an incomplete or erroneous security constraint in e3config.xml. For example, a constraint might not have an access parameter, a constraint with an access parameter value of restricted might not have a role parameter defined, or the test set might reference a non-existent standalone test set. The Arbortext PE Request Manager will check for such inconsistencies when it initializes and reads e3config.xml.  For each error it finds, it will make an entry in its error log. Be aware of the following items:
• If a constraint's test set does not exist, or contains tests that are invalid, the constraint will match all requests.
• If the Arbortext PE Request Manager detects any error, the security constraint will behave as if it has an access parameter value of disabled.  This will result in any request that the security constraint handles being rejected, with errors returned to the client and written to the servlet log.
Security constraints are described on the Arbortext Publishing Engine status report. The entry for any inconsistent constraints will state that the constraints are inconsistent.