Protecting specific RuleApps

You can configure security at the RuleApp level. However, it means that you have to update the web.xml deployment descriptor file every time a different RuleApp is deployed.

Before you begin

Restriction: If you frequently add or modify your RuleApps, you might not want to take this approach because the protection works only on that RuleApp.

About this task

Each deployed RuleApp leads to a different endpoint. For example, loan-related applications are in a RuleApp called loans, while pricing-related applications are in a RuleApp called pricing.

When they are deployed, these two RuleApps create different endpoints:

https://app.example.com:9443/odm/test/DecisionService/rest/loans/…
https://app.example.com:9443/odm/test/DecisionService/rest/pricing/…

The two distinct URL patterns /rest/loans/* and /rest/pricing/* can be used to protect the invocation of the corresponding RuleApps. They can also use different roles.

Procedure

See the following example of web.xml:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>REST API for Loan</web-resource-name>
        <url-pattern>/rest/loans/*</url-pattern>
        <url-pattern>/ws/loans/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>resLoansUsers</role-name>
    </auth-constraint>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>REST API for Pricing</web-resource-name>
        <url-pattern>/rest/pricing/*</url-pattern>
        <url-pattern>/ws/pricing/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>resPricingUsers</role-name>
    </auth-constraint>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>