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 type | Description/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 groups | Example: group.staff, group.admin |
| User Roles | Example: role.security.officer, role.enduser, role.administrator |
| Resources | Example: appl.useradministration, appl.selfadministration, appl.ebanking |
| Resource Addresses | Example: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.