Servoy Magazine

[Article] Customizing Security for Servoy Solutions

by Adrian McGilly
Information Systems Consultant

1 Quick overview of the Servoy Security Tool

Servoy provides a powerful security tool which you can access under the Tools menu if you are logged in as an Administrator. This tool lets an Administrator create users & groups, assign users to one or more groups and define the privileges of each group. This information (usernames, passwords, groupnames and group privileges) is all stored in the repository.

The Security tool makes sure that you never lock yourself out by insisting that there always be at least one user in the Administrator group. So as long as you remember that user's username and password, you will always be able to log into any solution, and you'll always be able to get into the Security tool to make changes to security settings.

The tool also provides a 'Solution Login Required' option, illustrated below:

This option applies specifically to the solution you're in at the time. Upon opening any solution, Servoy will only prompt the user for username and password if this option is turned on for that solution.

Note that whenever a user logs in, they are not only logging into the solution, they are logging into the repository, and they will remain logged into the repository until they either log out (using the File>>Logout command) or until a method logs them out. This means that if you give a user access to several solutions in the same repository, once logged in, he will be able to move freely among them without having to log into each one.

2 Customizing Servoy Security

Usually a developer will want the exclusive right to create groups and define group privilges, but in many cases developers will want to delegate to some designated end-user(s) the responsibility of creating/editing/deleting user accounts.

2.1 The Security Class of functions

To enable this, Servoy provides a class of methods called security which gives the developer all the methods required to manage user accounts from within the solution rather than relying on the Security tool. Using this approach it is no longer necessary to create usernames & passwords in the Security tool and assign users to groups - you can simply store usernames, passwords, group assignments (and whatever other user profile information you might want) in a 'users' table in your database. When a user tries to log in, you can validate the username & password against this 'users' table and if it passes validation you can log them in using the security.login() method, specifying as parameters:

• the username
• a userID
• the group the user belongs to

As long as the specified group exists in the Security tool, the security.login() function will log the user in with the privileges for that group. (It is in fact possible for a user to belong to several groups at once, and Servoy handles this very nicely, but that's beyond the scope of this article).

For organizations that have users & groups already defined in an LDAP server, you can use the LDAP plugin from IT2BE (www.it2be.com) to validate a username & password against the LDAP server before using this security.login()function to log the user into Servoy. This will spare you having to maintain a separate user list in Servoy.

2.2 Custom login form

Servoy also lets you create your own custom login form. To use a custom login form you need to specify the form as the login form in the Solution Settings. When a solution is opened, the custom login form will be displayed before any other form is opened or any other method is run. Specifically it will supersede the 'First Form' and the 'On Open Method' solution settings. However, the custom login form will only appear if the the 'Solution Login Required' option is turned on for that solution.

Once open, the custom login form will remain open and no other forms can be opened until one of these things happens:

1. the security.login() method is executed and successfully logs the user in. In this case, Servoy immediately runs the 'On Open Method' method from the solution settings, and then opens the form specified by the 'First Form' setting.

2. security.logout() or application.exit() or application.closeSolution is executed (there may be other 'exit' paths available but I know these three work)

3 McGilly_Security: Custom Security Module

The McGilly_Security module is a free security module which you can download here. It lets you add a basic set of custom security features to a Servoy solution , and these features can be further customized as needed. The module was developed by Adrian McGilly in collaboration with Carmen Scoma of Home Health Digital Services (HHDS).

3.1 Main features

Here are the main features of the module:

• Provides forms for creating/editing/deleting user accounts in a users table in your db (NOT in the repository). When using this module it is not necessary to create any users in the Servoy Security tool.
• Note that passwords are not currently encrypted - if this is a requirement, you will need to acquire the Cryptor encryption plugin from IT2BE (www.it2be.com).
• Each user can be assigned to exactly one group (which differs from the Servoy Security tool, which allows you to assign a user to several groups at once).
• The group names are defined in a custom valuelist which you can edit as needed. Just make sure that the groups in this valuelist also exist in the Servoy Security tool. (The reverse is not requried, i.e. it is NOT necessary for every group that is defined in the Servoy Security tool to also appear in the valuelist. This gives you the flexibility to have some groups that are 'beyond the reach' of your users.)
• Includes a custom login form which validates username & password against the users table before logging the user in.
• All objects in the module have the prefix "sec_", to help you distinguish them from other objects in your solution, and to help avoid naming conlicts with your solutions. (The one exception to this rule is the table called 'users'). All methods are well documented.

Additional features of the module include:

• In addition to validating username & password against the users table, the login logic also recognizes any user that is defined explicitly in the Servoy Security tool, even if that user doesn't exist in the users table. This provides a 'back door' for high-level users and developers to log into a solution. In this document I refer to these users as 'back door users'. If the same username exists both in the users table and the Security tool, the user account defined in the Security tool (i.e. the 'back door user') will be used to log the user in.
• By using SQL rather than controller functions the module specifically avoids establishing or accessing a foundset based on the users table during the login process. This ensures that upon successful login, you can apply table filters to the users table if your solution calls for it, which is a likely requirement in multi-company solutions. (The way Servoy implements table filters, they can't be applied once a foundset has been accessed by a solution). This is also why the login form called 'sec_login' is based on a table called 'sec_dummy' that contains a single record. If it were based on the 'users' table then from the moment the sec_login form is opened, the parent solution would be prohibited from applying table filters to the users table.
• Populates the following global variables/relationships which can be used in the rest of your solution:
  
  

  sec_current_user	global relationship, points to the current user's record in the users table (unless current user is a 'back door user' in which case this relationship is undefined)
  globals.sec_login_username	global dataprovider, contains current user's username
  globals.sec_login_group	global dataprovider, contains current user's group. ('Administrator' for any back door user)
  globals.sec_login_user_id	global dataprovider, contains user_id of the user's record in the users table (undefined for back door users)

3.2 Instructions for Use

1. The first step is to open the solution to which you want to add these security features and create all the Groups you need in the Servoy Security tool (Tools>>Security). There is no need to create any users in this tool, although you can if you want to.

2. The module relies on two tables: 'users' and 'sec_dummy'. The users table will hold all your users info (usernames, passwords, etc). The 'sec_dummy' table contains only one record and is required by the custom login form called 'sec_login'.

Before importing the module you need to decide where (i.e. in what database) you want these tables to reside. If you have an active db server called 'example_data' at the time of the import then by default the import engine will create these tables there. If at this time you are just experimenting and you want the tables to reside in the example_data server, then just go to the next step. Otherwise, go to Edit>>Preferences>>DB Servers and take the example_data server offline before proceeding. This will cause the import engine to prompt you for the db server where you want these tables to reside.

3. Import the McGilly_Security.servoy module:

• When asked if you want to import the sample data contained in the export, say 'Yes'.
• As mentioned above, if there is no example_data server available, you will be prompted during the import process for a target db server in which to created the users and sec_dummy tables.

4. Now open the McGilly_Security solution. You will see this form:

This form is called sec_users. It is where you add/edit/delete users. But before you do this, you must tell the module what groups you want in your security system. To do this, go into design mode and edit the valuelist called sec_groups so that it contains exactly the groups you want for your security system.

Remember that any group you put in the valuelist must also exist in the Servoy Security tool in order for users to be able to login as members of that group. (Conversely, it is OK to have groups in the Servoy Security tool that don't exist in this valuelist.)

Now you can add/edit/delete users. You can also do this in step 8, once the security module is incorporated into a parent solution.

5. Add the McGilly_Security module to a solution you want to secure. (To do this, open the target solution, go to File>>Solution Setting, click the "Add" button and select the McGilly_Security module.)

6. Close and re-open the parent solution.

7. Under File>>Solution Settings, set the Login Form setting to 'sec_login'. This is the form in the McGilly_Security module that prompts the user for username & password and performs the login operations.

8. Now, if you want to add/edit/delete users, you need to navigate to the form called sec_users which you saw in step 4 (you can use the windows menu to get there) where you will be able to do that.

9. The last step is to tell Servoy to require users to log into this solution. ONLY DO THIS IF YOU ARE SURE YOU KNOW THE ADMINISTRATOR USERNAME AND PASSWORD AS DEFINED IN THE SERVOY SECURITY TOOL. Once you're sure, go into the Servoy Security tool and check the 'login required' checkbox.

10. Now close and re-open your solution. You will be prompted for a username and password using the module's sec_login form.

If you provide a valid username/password from the users table, you'll be allowed in. Alternatively, if you provide a valid username/password from the Servoy Security Tool, you'll be allowed in.

If you are already logged in as one user and attempt to log in as a different user, the security module will first log out the current user, which closes the solution (but leaves you in Servoy).