Authorization Concepts

Nevis supports a security role model that permits granting users restricted access to applications. The functionality is split into two parts:

1. nevisAuth maps user data, resource information, and authentication mechanisms to a flat security model. The complexity of this security model is site-specific (see Proposed security role model for further information).
2. The reverse proxy enforces the required roles and calls the step-up method of nevisAuth once to check whether access is granted (possibly with the need to provide more user credentials, e.g., a one-time password).

This security role model allows the following access control features:

• Assign an individual authentication strength to each application.
• Deny access to applications that require the user to be in a specific user group or have certain roles.
• Deny access to whole applications that the user is not authorized to use.
• Deny access to application parts that the user is not authorized to use. (This only works when the URL namespace of an application permits a distinction of functions and the authorization model is functional.)

Proposed security role model

The example below contains a proposition for a complex security role model that requires a corresponding data model. The security role names below are a proposal to enforce certain rules for naming security roles. nevisAuth itself supports specific security models, but it does not enforce them. Specific security models are provided by authentication plug-ins and are documented along with the respective component.

A plug-in that supports a security model as proposed here is implemented with the Nevis user database access plug-in.

• Authentication strength (propagated by nevisAuth authentication back ends or plug-ins)

  Depending on the authentication mechanism used (e.g., UserID/password, PUI/PIN, certificates, etc.), the strength of the authentication should be signaled.

  Samples:

  • auth.anonymous: User is unknown
  • auth.identified: UserID was provided and found, but no credentials
  • auth.weak: Simple userID/password-style authentication
  • auth.strong: Additional one-time password

  The levels may also be numbered (e.g., auth.level1 .. auth.level20), but they should never reflect the mechanism (e.g., auth.securid).

• User groups: group.staff, group.admin

• User Roles: role.security.officer, role.enduser, role.administrator

• Resources: appl.useradministration, appl.selfadministration, appl.ebanking

• Resource Addresses: url:/appl/module/function/write

To comply with the above security role model, you need separate data sources for users, resources, and authentication mechanisms:

• User data (mandatory): Contains users and credentials and should provide group and role entities if required. May also contain information about the applications for which a user is authorized. This data is usually dynamic (changes daily) and should be managed in a database.
• Resource data (optional): Contains all existing applications and may provide an authentication strength assigned to an application. Fine-grained authorization models are optional. A security proxy can only enforce a fine-grained functional authorization model when the URL namespace of the application reflects the functions called. This data is usually somewhat static (changes monthly) and should be managed in a database.
• Authentication mechanisms (recommended): The quality of authentication mechanisms is usually settled once per site, and the respective data is therefore almost static (changes once per year or less). It is typically deployed with a new mechanism and may be deployed with the current nevisAuth configuration.