Configuring authorization

When using an authentication infrastructure that also provides authorization profiles (mapped as a flat security model as described in chapter Proposed Security Role Model of the nevisAuth Reference Guide), nevisProxy also provides support for authentication stepup and access control. Authentication stepup Authentication stepup is performed when the SecurityRoleFilter requires security roles, and the user has none of the required roles. The filter triggers an authentication stepup, which may require additional user credentials (e.g., a one-time password), and may in turn return one of the requested roles. If no required security role is returned, access is denied (also for subsequent requests on the same resources).

The configuration sample shown here after, adds access control by using two roles, representing authentication strength (auth.weak and auth.strong) as well as a an authorization to access an application as a customer (role.customer).

The following scenario shows the details:

Event	Required roles	Accumulated roles from authentication and/or stepup	Result
User2 accesses /appl1/weak and logs in with userid/password.	auth.weakrole.customer	auth.weakrole.customer	User2 passes
User1, who is not registered as a customer, accesses /appl1/weak and logs in with userid/password.	auth.weakrole.customer	auth.weak (as the user is not a regular customer)	User1 passes Authentication and AuthWeak, but is blocked by RoleCustomer filter
User2 accesses /appl2 and is forced to provide a one-time password.	auth.strongrole.customer	auth.weakauth.strongrole.customer	User2 passes
User2 accesses /appl3	auth.strong	auth.weakauth.strongrole.customer	User2 passes

These configuration steps lead to the following entries in the web.xml file (using op nevisproxy config webapp):

<filter>
 <filter-name>AuthWeak</filter-name>
 <filter-class>ch::nevis::isiweb4::filter::auth::SecurityRoleFilter</filter-class>

 <init-param>
   <param-name>AuthenticationServlet</param-name>
   <param-value>EsAuthConnector</param-value>
 </init-param>
 <init-param>
   <param-name>LoginRendererServlet</param-name>
   <param-value>LoginRenderer</param-value>
 </init-param>
 <init-param>
   <param-name>RolesRequired</param-name>
   <param-value>auth.weak auth.strong</param-value>
 </init-param>
</filter>

<filter>
 <filter-name>AuthStrong</filter-name>
 ....
 <init-param>
   <param-name>RolesRequired</param-name>
   <param-value>auth.strong</param-value>
 </init-param>
</filter>

<filter>
 <filter-name>RoleCustomer</filter-name>
 ....
 <init-param>
   <param-name>RolesRequired</param-name>
   <param-value>role.customer</param-value>
 </init-param>
</filter>

<filter-mapping>
 <filter-name>AuthWeak</filter-name>
 <url-pattern>/appl1/weak/{*}</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>AuthStrong</filter-name>
 <url-pattern>/appl2/{*}</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>AuthStrong</filter-name>
 <url-pattern>/appl3/{*}</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>RoleCustomer</filter-name>
 <url-pattern>/appl1/weak/{*}</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>RoleCustomer</filter-name>
 <url-pattern>/appl2/{*}</url-pattern>
</filter-mapping>

The order of the two mappings, the IdentityCreationFilter and the SecurityRoleFilter, is important because they are matching the same URLs. The IdentityCreationFilter must be configured first to establish an initial session.