Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

• Document Overview
• Understand the security model of Apache Fortress Web
• SECTION 1. TLS
• SECTION 2. Java EE security
• SECTION 3. Spring security FilterSecurityInterceptor
• SECTION 4. Apache Wicket Links
• SECTION 5. Apache Wicket Buttons
• SECTION 6. Additional Administrative Role-Based Access Control (ARBAC) Checks
• SECTION 7. Policy load
• SECTION 8. Verification

• Provides a description of the various security mechanisms that are performed during Apache Fortress WEB runtime operations.

               .---------.      
               | Browser |      
               '----.----'      
                    | HTTPS
            .-------'------.
            | FortressWeb  |
            '-------.------'
                    | in-process
            .-------'------.
            | FortressCore |
            '-------.------'
                    | LDAPS
          .---------'-------.
          | DirectoryServer |
          '-----------------'

• Consists of three tiers: 1. Browser, 2. Servlet Container hosting FortressWeb, and 3. DirectoryServer that stores the policy information.
• FortressWeb is a web application archive (.war) that deploys into a Servlet Container, i.e. Apache Tomcat.
• FortressCore is a set of APIs that get embedded inside of Java apps, FortressWeb and Fortress Rest.
• DirectoryServer is a process implementing LDAPv3 protocols, e.g. ApacheDS or OpenLDAP.

• The user credentials are introduced into the call chain by the Client as a standard HTTP basic auth header.
• Passed into the Servlet Container for authentication and coarse-grained authorization before dispatch to FortressWeb.
• Spring security verifies user has role to view the web page.
• Medium-grained authorization performed inside the pages via Apache Wicket controls button and link visibility.
• The RBAC session passed into the FortressCore for fine-grained checks.

Be sure to use because it allows confidentiality of credentials and message content via HTTPS. Refer to the documentation of your servlet container for how to enable.

• FortressWeb uses the Apache Fortress Realm to provide Java EE authentication, coarse-grained authorization mapping the users and roles back to a given LDAP server.
• This interface requires standard HTTP Basic Auth tokens for the userid/password credentials.
• The credentials are verified by the Apache Fortress Realm via bind op invocation to the Directory Server.
• The coarse-grained authorization policy ensures callers have been assigned at least one of the following roles to successfully navigate to any page:
  1. ROLE_ADMIN
  2. ROLE_USERS
  3. ROLE_ROLES
  4. ROLE_PERMS
  5. ROLE_SSDS
  6. ROLE_DSDS
  7. ROLE_POLICIES
  8. ROLE_PERMOBJS
  9. ROLE_USEROUS
  10. ROLE_PERMOUS
  11. ROLE_ADMINROLES
  12. ROLE_ADMINOBJS
  13. ROLE_ADMINPERMS
  14. ROLE_AUDIT_AUTHZS
  15. ROLE_AUDIT_MODS
  16. ROLE_AUDIT_BINDS
  17. ROLE_GROUPS

• per its deployment descriptor, web.xml.

• The page-to-role mappings are enforced by Spring security as defined applicationContext
• The following table illustrates the mapping:

• For example, the administrator must have the 'ROLE_GROUPS' role activated into their session before Spring security allows entry to the 'GROUPS' page.

• The page links are controlled by the same RBAC Role assignments as the Spring security checks.
• For example, the administrator must have the 'ROLE_GROUPS' role activated into their session before Wicket will show the 'GROUPS' link on any page.
• The Spring and Wicket enforcements overlap. An example of 'Defense in Depth'. Both mechanisms must pass before an administrator is allowed to view any page.

• The page buttons are protected by Administrative perms.
• For example, the administrator must have the 'AdminMgrImpl:addRole' perm activated before Wicket will show the add button on the 'ROLES' page.

• Below are list of Admin perms (1), Pages (2), and the admin role mappings (3 - 6).
• Each perm maps to a single button on a single page.

• For example, the administrator must have the 'GroupMgrImpl:add' perm activated into their session before Wicket will show the add button on the 'GROUPS' page.
• These policies are defined here: FortressWebDemoUsers

• Apache Fortress Web applies two types of security semantics: RBAC and ARBAC.
• Their respective policies get stored inside separate trees in LDAP.

Sample Directory Information Tree:

dc=example,dc=com
 ├─ou=rbac  <- 'normal' RBAC data
 │  ├─ou=roles
 │  └─ou=perms
 ├─ou=arbac <- administrative RBAC data (ARBAC)
 │  ├─ou=roles
 │  └─ou=perms
 ├─ou=people
 └─ou=groups
 ...

• RBAC roles and perms are stored and used on behalf of business apps. For 'typical' security use cases.
• RBAC roles are also checked by the Spring and Wicket enforcement layers mentioned earlier.
• ARBAC roles and perms are checked when edits are made to RBAC policies. Like what the Apache Fortress Web does.
• Users and Groups can be assigned both RBAC and ARBAC roles.
• For example, an administrator would be assigned the 'ROLE_GROUPS' RBAC role + the 'fortress-web-group-admin' ARBAC role to be allowed entry to the 'GROUPS' page and use its buttons.

Fortress Web optionally enforces more rigorous checks.

• For more on ARBAC checking: Apache Fortress Rest Security Model
• By default, ARBAC is disabled in the Apache Fortress Web runtime.
• To enable, add the following to fortress.properties:

is.arbac02=true

Pros:

1. Mandatory Access Controls

• Every Fortress API is guarded by an automatic permission check.
• More granular than buttons. One button may invoke two APIs.
• The Wicket and ARBAC enforcement layers overlap. Both mechanisms must pass before an administrator is allowed to call an API.

2. Delegated Administration Checking

• Enforces administrator actions across entity sets on behalf of a particular organization.
• The administrator must be granted access before an organization's user can be modified and before any of its roles or permissions can be assigned.
• For detailed description, checkout the Rest Security Model document.

3. Auditing and History

• Using OpenLDAP's slapo-access log a complete audit trail can be stored.
• Logs all actions, entity history, binds and authorization attempts, etc.

These Fortress Web pages are for viewing the audit log:

• BINDS - authentication attempts
• AUTHZ - authorization attempts
• MODS - history of changes to data

Cons:

1. Can be difficult to setup.

• We've given a head start with sample ARBAC policy load files.

2. It's complicated.

• The user and perm ou and range checks are hard to conceptualize and may not be required.

• The Policy load file is a script that creates the roles and permissions that this app checks during code execution. This step is performed during setup as described in the project's setup documentation.
• Test Users

• All test passwords = 'password'

• Run the Selenium Tests: FortressWebSeleniumITCase
• Required security policy for selenium tests is loaded: a or b and c:
  • a. ARBAC Policy Load: DelegatedAdminManagerLoad
  • b. Fortress Junit Tests: FortressJUnitTest
  • c. Fortress Web Demo Load: FortressWebDemoUsers