You can use MDriven Turnkey to define and enforce which information each authenticated user may receive, while still delivering a responsive client experience.
Information security is controlled risk
Information security protects information in an IT system from access or change by the wrong person. It does not mean eliminating every risk; attempting to eliminate all risk can prevent people from doing their work.
Choose an acceptable risk level for each kind of information. Consider both the value of individual records and the value created when records are combined. For example, one customer record may be low risk, while an export containing all customers can require stronger protection.
Start with the basic hygiene that every system needs:
- Authenticate users so that the system knows who is requesting access.
- Authorize each user according to defined rules.
- Keep computers and software maintained and free from unwanted software.
This page focuses on the application-design problem: how your system gives authenticated users access to the information they are allowed to use in an environment where client computers cannot be treated as fully trusted.
Keep the access-control decision on the server
An Access Control System is the part of an application that decides whether a user can access information or perform an operation. An identity provider or directory can identify a user and provide credentials, but the application must still enforce its own access rules.
The central goal is:
Deliver only the approved slice of information to each authenticated user.
The access-control system must be able to evaluate the information it protects, then reduce it to the subset that the current user may receive. For example, a sales representative may be allowed to receive the orders assigned to that representative, while a manager may receive orders for the whole team.
Do not move this filtering decision to the browser or another client. A client can hold data between navigations, and client-side code can become difficult to review. If the client receives data first and filters it later, it has already received information that may not be permitted.
Treat clients and servers differently
A user laptop or browser is not a trusted place to enforce access control. It can be exposed to unwanted software or other compromise. Hardening endpoint computers remains important, but it does not make them a suitable place for the application lock.
A maintained server in a controlled environment is generally the appropriate place for the application and its access-control system. This does not remove the need for server security. Configure transport security and MDrivenServer administration as described in Training:Security concerns for MDriven Server. In particular, use HTTPS when communicating with MDrivenServer, and protect the administration interface from unauthenticated access.
How MDriven Turnkey applies this model
MDriven Turnkey keeps the access-control system on the server and uses ViewModels to define the information a user receives for a use case.
A ViewModel is the application-facing representation of information and interaction for a specific task. Its data reduction is evaluated on the server. The resulting information slice, and changes to that slice, are streamed to the client. This supports a rich client experience without giving the client the complete model data to filter itself.
The rules are declarative OCL expressions in the model. This makes the access rules inspectable as model expressions rather than requiring reviewers to infer the security boundary from client code.
| Requirement | MDriven approach | Example |
|---|---|---|
| Identify the user | Make the current user available in the model. | A user record has IsAdmin or belongs to a role.
|
| Restrict repeated rules | Use an AccessGroup for actions and ViewModels that share a rule. | The MustBeAdmin group controls several administration actions.
|
| Restrict a particular action | Set the action's Enable expression. | A user can approve an order only while it is awaiting approval. |
| Restrict a widget in a view | Set its Visible and/or ReadOnly expression. | A salary field is visible only to an authorized manager. |
| Restrict an entire ViewModel for its root object | Set the ViewModel Access expression. | A user can open an order detail ViewModel only for an order assigned to that user. |
Define access rules in the model
Use your domain model to express the rules that matter to the business. The following workflow keeps rules consistent and reviewable.
- Model the user and the information relevant to authorization, such as roles, assignments, ownership, or approval state.
- Make the current user reachable from the model. A common pattern is a
SysSingletonclass with a derived link toCurrentUser. - Use OCL to evaluate the rule. For example, an expression can test whether the current user is an administrator:
SysSingleton.oclSingleton.CurrentUser.IsAdmin=true
- Put rules shared by multiple actions or ViewModels in an AccessGroup.
- Use a ViewModel Access expression when access depends on both the user and the ViewModel root object.
- Test the same use case as users with different access rights, including a user who must be denied access.
For a detailed description of AccessGroups, Enable, Visible, ReadOnly, and ViewModel Access expressions, see Training:Access control system in MDriven.
Example: restrict a treasury view
Assume a model contains users, roles, and a treasury ViewModel. A static role rule can determine whether a user is a member of a role:
SysSingleton.oclSingleton.CurrentUser.SysRoles->exists(name='fisherman')You can place a shared rule such as this in an AccessGroup when several actions and ViewModels require it. Use a more specific expression on an individual action when its availability also depends on the current business state.
For example, an action may remain visible so the user understands that it exists, but be disabled when the order is not ready. In a different situation, you may hide an action or widget entirely. Choose deliberately between these outcomes:
| Outcome | Use when |
|---|---|
| Visible and enabled | The user is authorized and the operation is currently valid. |
| Visible but disabled | The user may need to know the operation exists, but cannot perform it in the current state. |
| Not visible | Showing the operation or information is not appropriate for that user. |
| Access denied for the ViewModel | The user must not open the ViewModel for the given root object. |
If a ViewModel Access expression evaluates to false, MDriven looks for a ViewModel named AccessDenied and shows it. If no such ViewModel exists, the result is a blank screen. Before an action opens a protected ViewModel, use canAccess(vmname):bool to test access and avoid navigating a user to an unavailable view or generating a report from a ViewModel the user cannot access.
Design and review checklist
Before releasing a use case, verify the following:
- The system authenticates the user before protected information is requested.
- The ViewModel defines the information slice for the use case.
- Authorization rules are evaluated on the server.
- Shared rules are centralized in AccessGroups rather than copied across many actions.
- Rules that depend on a particular root object use the ViewModel Access expression.
- Sensitive fields use Visible or ReadOnly expressions where appropriate.
- A denied ViewModel has an intentional
AccessDeniedexperience. - You have tested authorized and unauthorized users against the same data and root objects.
- MDrivenServer uses HTTPS and its administrative and exposed service access settings have been reviewed.
Authentication and access control
Authentication establishes the current user. Authorization rules in the model decide what that user can view or do. MDriven Turnkey authentication uses OAuth2 and can be implemented with social login or single sign-on using OpenId. You can make multifactor authentication part of the overall access-control arrangement.
The exact authentication mechanism can vary between web and desktop scenarios. Keep the application rule independent of that mechanism: once the platform identifies the current user, expose the relevant user information to the model and evaluate authorization through model rules.