You can add the supplied authentication model to your Bootcamp application and use it to control which ViewModels logged-in users and administrators can open.

This is Chapter 11 of the MDriven Bootcamp. Continue from Chapter 10, or return to Chapter 1 if you need to restart.

What you will build

In this chapter, you merge the SysUserAuthentication model and then use its types to:

• keep the current user in a singleton object;
• add common creation and update information through a default superclass;
• register and log in users in the local Turnkey application;
• restrict a ViewModel to logged-in users; and
• restrict SysUser administration to administrators.

The example uses the CarSeeker ViewModel as a page that requires a login and the SysUser autoforms as pages that require administrator access.

Merge the authentication model

1. In the MDriven wiki, open Model Examples and download the SysUserAuthentication model.
2. Open your Bootcamp model in MDriven Designer.
3. Open and merge the downloaded model into your model.
4. Save the merged model.

The merged model contains an authentication package, including SysSingleton, SysSuperClass, and SysUser.

Understand the singleton and current user

A singleton is a class for which the running system uses one shared object. In this model, SysSingleton provides that shared object, and its CurrentUser association identifies the user currently logged in.

1. Select SysSingleton in the class diagram.
2. In the object inspector, verify that IsSingleton is set.
3. Select the CurrentUser association on SysSingleton.
4. Verify that Persistent is false.

A non-persistent association is transient: it represents runtime state and is not stored as persistent data. Here, the current login is runtime state rather than a permanent property of a user object.

Test the singleton in the prototyper

1. Start the system prototyper with XML persistence.
2. Open the debugger.
3. Enter the following OCL expression and execute it with F5:

SysSingleton.oclSingleton

You should receive an object. This is the shared SysSingleton object used by the running prototype.

Use SysSuperClass as the default superclass

SysSuperClass provides common behavior for classes in a package. Inspect its OnCreate and OnUpdate definitions and use the debugger to observe when they run. In this chapter, you use it to make a change timestamp available on Person.

1. Select SysSuperClass in the diagram.
2. Inspect its OnCreate and OnUpdate settings.
3. Verify that SysSuperClass is the default superclass of AuthenticationPackage.
4. Set the default superclass of Package1 to SysSuperClass.
5. Refresh the model or restart the debugger.
6. Inspect Person. Verify that it now has the ChangeTime attribute.

A default superclass applies inheritance to the classes in the package. For example, after setting Package1's default superclass, Person inherits the common members supplied by SysSuperClass.

Verify inheritance with OCL

In the debugger, execute each expression below. oclIsTypeOf checks an exact type, oclIsKindOf checks a type relationship, and superTypes returns the superclass types.

Expression	Expected result
SysSingleton.oclSingleton.oclIsTypeOf(SysSuperClass)	True (shown as a check mark)
SysSingleton.oclSingleton.oclIsKindOf(SysSuperClass)	True (shown as a check mark)
SysSingleton.superTypes	SysSuperClass

Update existing Person objects

Existing Person objects need a Guid value for the later exercises.

1. In the debugger, change the expression mode from OCL to an Action expression by selecting Action.
2. Enter the following expression:

Person.allinstances->collect(p|p.Guid:=Guid.NewGuid)

1. Execute it with F5.
2. Verify that each Person now has a new Guid value.
3. Save the data.
4. Save the Person objects and verify that ChangeTime updates.

The expression collects all Person instances and assigns a newly generated Guid to each object.

Register and inspect a user

1. Start the Local Turnkey Prototyper.
2. Attempt to log in with any user.
3. Register a new user with an email address and password.
4. Return to the debugger and execute:

SysUser.allinstances

Verify that the registration created a SysUser object.

Restrict CarSeeker to logged-in users

An access group is a named condition that controls whether a ViewModel or action is viable and enabled. The supplied IsLoggedIn access group is used to make CarSeeker available only after a successful login.

1. Open the ViewModel Editor.
2. Select the CarSeeker ViewModel.
3. Set its AccessGroups value to IsLoggedIn.
4. Save the model.
5. Test the web application while logged out. Verify that CarSeeker is not available.
6. Log in and verify that CarSeeker becomes available.
7. In the top menu, select the AccessGroup tool button next to the Actions Editor button.
8. Inspect the expressions that define IsLoggedIn and confirm how they determine the logged-in state.

Create an administrator access group

Create an IsAdministrator access group for views that expose user administration.

1. In the AccessGroup editor, add an access group named IsAdministrator.
2. Set both its Enable Expression and Viable Expression to:

SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

1. Save the model.

This condition evaluates the IsAdmin property of the user associated with SysSingleton.oclSingleton.CurrentUser.

Protect the SysUser autoforms

1. Refresh AutoForms and verify that autoforms are created for SysUser.
2. Open AutoFormSysUser in the ViewModel Editor.
3. Set its access group to IsAdministrator.
4. Save and test the web application as a non-administrator.
5. Verify that access is denied when the user attempts to open the protected view.

Create an AccessDenied destination

Create a ViewModel named AccessDenied to explain that the user does not have permission to access the requested view.

1. Create a new ViewModel named AccessDenied.
2. Add a row by double-clicking in the ViewModel editor.
3. Configure the row to present an access-denied message.
4. Save the model.

The exact row expression or presentation configuration for this message must match the intended Bootcamp model configuration.

Make an existing user an administrator

1. Set the access group of AutoFormSysUserSeeker to IsAdministrator.
2. In the debugger, re-read the model.
3. Execute SysUser.allinstances and save the result context.
4. Open the SysUser Seeker, select a user, select the IsAdmin check box, and save.
5. Return to the web application and verify that this administrator can open AutoFormSysUserSeeker.

Verify access with two users

1. Create another user, for example b@b.se.
2. Log in as the new user.
3. Attempt to open AutoFormSysUserSeeker.
4. Verify that the non-administrator cannot open it and is directed to the AccessDenied ViewModel.

You now have two distinct authorization rules: IsLoggedIn protects CarSeeker, while IsAdministrator protects user-administration views. The next chapter applies these rules to control editing and visibility in the car application.

See also

• Bootcamp Chapter 10
• Bootcamp Chapter 12
• Bootcamp Chapter 5
• Learn OCL