You can deploy a model to MDriven Turnkey, require users to sign in, and use Access Groups to control which actions and ViewModels each user can see or use.

What you learn in this session

This session combines a cloud deployment workflow with Access Groups. An Access Group is a model-level rule that controls whether associated actions and ViewModels are visible and enabled.

Use this approach when an action is available only to a defined set of users. For example, a public visitor must not see Show all houses, while a signed-in user can see and run it.

Concern	What it answers	Example
Authentication	Who is the user?	A visitor registers and signs in with an email address and password.
Authorization	May that user access this action or ViewModel?	Only a user for whom the Only logged in Access Group evaluates as visible can open Show all houses.
Action enable state	Is the action currently valid for the selected data?	A Save action is disabled until required data has been entered.

Keep authorization in Access Groups. Do not use an action's ordinary enable expression as the primary authorization mechanism: that expression remains useful for data-state rules, such as whether an object can be saved.

Deploy a model to Turnkey

MDriven Turnkey runs the model you create in MDriven Designer. In the demonstrated cloud workflow, you can edit the model in MDriven Designer, upload it through the cloud dialog, refresh the Turnkey site, and continue iterating against the same data.

Provide the required start ViewModel

A Turnkey-driven site requires a ViewModel named Index. If the site reports that the Index page is missing:

1. In MDriven Designer, add a ViewModel.
2. Name the ViewModel Index.
3. Add the content that should be available when the site opens. For example, add a text field containing a short welcome message.
4. Open the cloud dialog and upload the model again.
5. Refresh the site.

After Turnkey finds the Index ViewModel, it can display the site's global actions as menus.

Include a user model when starting from a blank model

Turnkey needs a consistent way to identify users. A starter Turnkey model normally provides this. If you replace that model with a blank model, add the required user support before expecting sign-in-dependent behavior to work.

The session demonstrates importing the ASP.NET Identity snippet:

1. Download the ASP.NET Identity snippet from the MDriven Designer snippets area.
2. In MDriven Designer, import the snippet.
3. Optionally create or select a package to organize the imported model content.
4. Right-click the package's snippets area, select the imported ASP.NET Identity user snippet for Turnkey, and apply it.
5. Upload the amended model and test registration and sign-in again.

A package organizes model elements in a way similar to a namespace. Verify where the imported classes were added after applying a snippet; the session shows that they may be added to a different package than the one initially selected.

For deployment to your own Azure account, see Documentation:Hosting turnkey on my own Azure account. For an IIS installation, HTTPS requirements, and MDrivenServer configuration, see Documentation:Set up MDriven Turnkey on premise.

Control access with Access Groups

Create an Access Group when you want the same authorization rule to govern one or more actions or ViewModels.

Example: show navigation only to signed-in users

In this example, the application has actions named Show all houses and Show all persons. Anonymous visitors must not see either action.

1. Open the AccessGroups Editor in MDriven Designer.
2. Create an Access Group named Only logged in.
3. Define the group's visible rule so that it evaluates true only when the current user is not empty. In the session, this is evaluated by starting at the singleton instance, following its currentUser association, and testing that a user is present.
4. Associate Show all houses and Show all persons with Only logged in.
5. Upload the model to Turnkey.
6. Open the site while signed out. The associated actions are not shown.
7. Register or sign in, then refresh or navigate again. The actions are shown when the current-user rule evaluates true.

The expression is OCL: Object Constraint Language expressions navigate your model and evaluate a condition. Use the actual singleton class and current-user association in your model; the important rule is that the current user must exist.

Protect the ViewModel as well as its action

Hiding an action does not by itself protect a web address. A user who knows the URL of a ViewModel may attempt to open it directly.

Associate the ViewModels themselves with the same Access Group:

1. Select the ViewModel, such as the ViewModel that lists all houses.
2. At the AccessGroups label, select the three-dot button to open the Access Groups selection.
3. Select Only logged in.
4. Repeat for every ViewModel that must require sign-in.
5. Upload the model and test both navigation and a direct URL while signed out.

This ensures that the signed-in requirement applies to the page, not only to the menu entry that opens it. For broader guidance on applying Access Groups to ViewModels and on data-access choices, see Documentation:Restricting data access.

Add role or situation rules

You can create multiple Access Groups for the authorization logic in your application. A group can represent a role, a user attribute, or another situation in the model.

For example, after establishing that a current user exists, an administrative group can navigate from that user to its role-related data and test whether the required role is present. Associate an administrative action and its ViewModel with that group so users outside that role do not see or access the administrative interface.

How multiple groups combine

An action can belong to more than one Access Group. For an action in Group1, Group2, and Group3, MDriven evaluates enablement as:

(Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable

Visibility is evaluated as:

(Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext

This means membership in any applicable Access Group can allow the group portion of the result, but the action's own enable state and context opt-in still apply. Define each group rule deliberately and test each user scenario.

Access Groups and Interest Groups

An Interest Group is not an authorization mechanism. It is a user-interface filtering mechanism that helps users find relevant actions in a large menu.

Type	Controls	Evaluation purpose
Access Group	Visibility and enablement for actions and ViewModels	Authorization: whether the user may see or use an item
Interest Group	Visibility of actions only	UI filtering: reduce menu clutter based on a user-selected interest or focus

Interest Groups are evaluated only when Access Groups are missing or have already evaluated visibility as true. Use an Access Group to prevent access; use an Interest Group to filter actions that the user is otherwise allowed to see.

Test the complete access path

Test authorization as a user would experience it:

1. Open the Turnkey site while signed out and confirm protected actions are absent.
2. Attempt to open each protected ViewModel directly by URL and confirm the ViewModel is also protected.
3. Register or sign in with a user that meets the Access Group rule and confirm the action and ViewModel are available.
4. Test a user that does not meet a role or situation rule.
5. Test ordinary action enablement separately. A user may be authorized to see an action while the action is disabled because the current data state is invalid.

See also

• Documentation:Access groups
• Documentation:Restricting data access
• Documentation:Faster prototyping with Turnkey
• Documentation:Hosting turnkey on my own Azure account
• Documentation:Set up MDriven Turnkey on premise