skip to main content
Corticon Server: Integration & Deployment Guide : Secure servers with authentication and encryption : Implementing deployment security : Setting up authentication for secure server access : Securing Server endpoints
 

Try Corticon Now
Securing Server endpoints
You can choose to restrict defined user roles to specified URLs – the endpoints that perform specific actions. You can put a constraint on a particular URL or many URLs associated with the web application. Endpoint security is defined in <security-constraint> tags.
<security-constraint>
<web-resource-collection>
<url-pattern>
You can define the URLs where the constraint will apply. For the constraint to be applied to all URLs associated with your web application, set the value to /*. However, a finer level of granularity can be applied. Here are the five core URL pattern matches associated with Corticon SOAP and REST API URLs:
1. Corticon Admin SOAP Servlet:
/services/CorticonAdmin
You can perform Admin operations over SOAP such as deployment or configuration of Decision Services. See Admin SOAP example.
2. Corticon Execute SOAP Servlet:
/services/CorticonExecute
You can execute Decision Services via SOAP requests. See Execute SOAP example.
3. Corticon Decision Service Admin REST:
/corticon/decisionService/*
Similar to the Admin SOAP endpoint, this endpoint is over REST. Because REST has a distinct URL for each operation, this endpoint uses an * for URL matching of all Decision Service Admin operations. See Admin DS example.
4. Corticon Server Admin REST:
/corticon/server/*
You can perform Admin operations against the Corticon Server over REST such as getting Corticon Server metrics and properties. See Admin REST example.
5. Corticon Execute REST:
/corticon/execute
You can execute Decision Services via REST requests. See Execute REST example.
<security-constraint>
<web-resource-collection>
<auth-constraint>
When the user passes in their credentials (username/password), the authentication process verifies that the credentials match a role that has been defined on the server. This section in the web.xml lets you limit access to the URL based on particular roles. If you don’t want to limit based on particular roles, then this value should be set to *.
However, you may not want everyone to have access to the Admin URLs. In this particular case, you must add a specific <security-constraint> for the Admin URLs with an assigned <role-name> to limit which types of users can access the URLs.
<security-constraint>
<web-resource-collection>
<web-resource-name>Corticon Admin SOAP Servlet Access</web-resource-name>
<url-pattern>/services/CorticonAdmin</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>ROLE_CorticonAdmin</role-name>
</auth-constraint>
</security-constraint>
Each role-name defined in any security-constraint in the web.xml must be defined in a <security-role> tag.
Example: (All role names)

<security-role>
<role-name>*</role-name>
</security-role>

Example: (Two specific role names)

<security-role>
<role-name>ROLE_CorticonAdmin</role-name>
</security-role>
<security-role>
<role-name>ROLE_CorticonExecute</role-name>
</security-role>
Note: If you want all role names to be valid for the web application, then add * in the XML Element. Even if you have set the constraint’s role-name to *, you have to define a <security-role> role-name with *.
* Using authentication in Corticon Studio
* Using authentication in client requests
* Using authentication within Web Console
* Using authentication in server test scripts
* Using API calls to a secure web application