You can use server-defined ViewModels to give users a rich, responsive interface while limiting each client to the information and operations required for its specific use case.

The exposure trade-off

Every business application has a trade-off between usability and exposure.

• A rich client needs data and interaction state close to the user so that the interface can respond to input.
• Information, business rules, and access-control decisions must not be trusted to a client controlled by the user.

Treat a browser, desktop client, or other user device as an untrusted environment. A user can inspect client-side code, alter requests, or construct requests outside the intended user interface. Hiding a button or relying on client-side logic is not an authorization boundary.

The goal is not to eliminate all risk. The goal is to choose an acceptable level of exposure for each type and aggregation of data, while still letting authorized users work effectively. For the broader security model, including authentication and authorization responsibilities, see Training:Information security.

Reduce exposure with a ViewModel

A ViewModel is the server-defined slice of information and behavior needed for one user task. Define the ViewModel for the task rather than exposing the complete domain model to the client.

For example, a Browse Videos screen may need to show:

• a filter string entered by the user;
• the name and length of each matching video; and
• the genre displayed for each video.

It does not need to expose:

• an operation that changes a video's genre; or
• information about who viewed a video previously.

The ViewModel is therefore the exposure boundary for that screen. A user who is authorized to browse videos receives the browsing slice, not the complete set of video data or all model operations.

Client requirement	ViewModel design	Exposure result
Show matching videos	Include only the attributes required by the list, such as name, length, and displayed genre.	The client does not receive unrelated video information.
Filter the list	Include a filter attribute and define the filtered collection on the server.	The filtering rule remains server-side.
Change a genre	Do not include a genre-changing action in a browse-only ViewModel.	A browse client has no ViewModel operation for that task.
Review viewing history	Do not include viewing-history information in the ViewModel.	The information is not part of the screen's data slice.

Keep rules and actions on the server

The client can display ViewModel data and report user input, but it must not be the authority for access rules or business rules.

Define ViewModel data reduction and derived values on the server using OCL (Object Constraint Language). OCL expressions give a declarative definition of what the ViewModel contains and can be statically verified in the model.

An action can be visible to a client by name without exposing its implementation. When a user invokes the action, the client asks the server to execute it. The server evaluates authorization and business rules, changes system state when permitted, and returns the resulting ViewModel changes.

This design protects against a modified client request being treated as proof that an operation is allowed. The server remains responsible for deciding what the authenticated user may see and do.

Stream changes instead of re-rendering the whole screen

MDriven Turnkey streams the ViewModel slice and subsequent changes to the client. This supports a rich user experience without sending the complete ViewModel again after every interaction.

A round trip carries changes in both directions:

1. The user changes a ViewModel value in the interface, such as entering text in a filter field.
2. The client sends the changed value to the server.
3. The server applies the value to the server-side ViewModel.
4. Server-side OCL dependencies are re-evaluated where the changed value affects them.
5. The server sends the resulting changes, such as items removed from or added to a filtered collection.
6. The client applies those changes to its local ViewModel state and refreshes the bound interface.

For the Browse Videos example, entering documentary in the filter can update the server-side filter value. The OCL expression that defines the displayed video collection is then re-evaluated. The client receives only the collection changes needed to show the new matching list, rather than a complete page reload.

The client can therefore provide data binding and immediate interface updates while the server retains the model logic, authorization decisions, and complete data set.

Design checklist

Use this checklist when deciding whether a screen has low or high exposure.

1. Define one ViewModel per user task or use case.
2. Include only the attributes, collections, and actions needed to complete that task.
3. Exclude sensitive attributes and related objects that the task does not require.
4. Define derived data and filtering rules with OCL on the server.
5. Treat every client request as untrusted; enforce access and business rules on the server.
6. Ensure that server-side actions, not client-side code, make state changes.
7. Review exposure when a ViewModel changes. Adding an attribute or action expands what that screen can expose.

What this approach does and does not protect

ViewModel-based reduction limits the information that a client receives for a specific use case. It does not replace the wider security work required for a deployed system.

You still need authentication, a defined authorization process, protected communication, and operational security for the computers and servers involved. MDriven Turnkey places the Access Control System on the server and streams the resulting authorized ViewModel slice to the client. Read Training:Information security for the full discussion of these responsibilities, including authentication options and communication protection.

See also

• Training:Information security
• Documentation:IsolationLevel
• Documentation:Trust and Guarantee
• Documentation:Why You Should Choose MDriven

Risk management strategies

You can manage information-exposure risk in an MDriven project by deciding what each user may see and do, then enforcing that decision on the server.

Risk management strategies

Risk cannot be eliminated without preventing users from working. Define an acceptable risk level for each type of data and for combinations of data. A collection of otherwise low-risk records can require more protection than one individual record.

1. Define the exposure for each use case

Use a ViewModel to define the information needed for one user task. The ViewModel is the data perspective that a user needs for that use case.

For example, a user who browses videos may need the video list and its visible attributes, but must not receive information that can change a Genre or reveal who viewed a film. Keep those attributes and associations out of the ViewModel for browsing.

2. Reduce data on the server

Perform ViewModel reduction on the server. In MDriven Turnkey, a ViewModel is implemented with declarative OCL, giving you an exact definition of the information subset that the authenticated and authorized user receives.

Do not rely on client-side filtering to protect data. The client must receive only the slice of data that the user is authorized to see.

3. Keep actions and rule evaluation on the server

Expose action names to the client, but execute the action on the server. When an action changes system state, the client requests its execution and receives the resulting ViewModel changes from the server.

For example, a browse screen can expose an action that a user may request, while the implementation that checks and performs the action remains on the server. This limits exposure of implementation details and prevents the client from becoming the authority for business rules.

4. Model access-control rules declaratively

Define the rules that make up the Access Control System in the model. Make the rules depend on the data in your model when required, and use static verification to review them.

This makes the access-control definition inspectable without reviewing client code. Security officers and other reviewers can examine the ViewModel and its rules to understand the exposure of an individual screen.

5. Authenticate users and organize authorization

Treat authentication and authorization as separate controls:

Control	Risk it addresses	MDriven approach
Authentication	An unknown user receives access.	Authenticate users. MDriven Turnkey authentication uses OAuth2 and can support optional social login or Single sign-on (SSO) with OpenId.
Authorization	An authenticated user receives data or actions outside the intended use case.	Define authorization keys and access-control rules from the model, then use the ViewModel to limit the data slice for that use case.
Multifactor authentication	A single authentication factor is insufficient for the required risk level.	Make multifactor authentication part of the Access Control System when the accepted risk level requires it.

MDriven Turnkey also supports server-to-server authentication using OAuth2.

6. Protect communication

Use SSL for communication between the user and server. Where stronger cryptographic protection is required, protect traffic between the user and server with a tunnel.

7. Review exposure as the model changes

Revisit the acceptable risk level when the data, its value, or its aggregation changes. Review each affected ViewModel and its access-control rules to confirm that the server still exposes only the information and actions required for the use case.

For example, when a screen that previously showed individual records is changed to show an aggregated list, assess the list as a new exposure. The aggregation can have a different risk level from the individual records.

See also

• Information security
• ViewModel for Business
• Learn OCL