Skip to main content
Version: 4.25.x.x LTS

Authorization Concepts

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

  • nevisAuth maps user data, resource information, and authentication mechanisms to a flat security model. The complexity of this security model is site-specific (see chapter Proposed security role model].
  • 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 in
  • 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 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.

Security role typeDescription/example
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 groupsExample: group.staff, group.admin
User RolesExample: role.security.officer, role.enduser, role.administrator
ResourcesExample: appl.useradministration, appl.selfadministration, appl.ebanking
Resource AddressesExample:http://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 usually deployed with a new mechanism and may be deployed with the current nevisAuth configuration.