DEXIT aCCESS Security

DEXIT security is designed to work on the desktop, and web versions of DEXIT , and supports single-tenant or multi-tenant setups.

In today's world no program, or user, stands alone. DEXIT is designed to integrate to a SendEmail or SendSMS function (or both). These allow features like second factor authentication, password resets, self-sign-up accounts and so on. 

If unauthorized users have access to the database, and they can tamper with fields (for example deleting them, or causing them to become invalid) or delete records, then certain DEXIT features may no longer be effective. For example if someone can Scan the security file, and remove a user record, then that user will no longer be able to log in.

For this reason physical access to the database should be restricted using whatever mechanism is appropriate for the database. For DEXIT this means adding an owner to the table. 

If an unauthorized person does get access to the database, data inside it will not be exposed. Any data they damage can be restored from backups, and the data itself will not be compromised.

Logins

The user logs in using a user name and password. However individual customers have individual requirements that can vary enormously from one customer to another. In addition the platform being used (desktop or web) may have special requirements that need to be supported.

To make logins as powerful, safe, and as feature-rich as possible - while at the same time making them easy enough to setup and use by mere humans has been a challenge. The result though is the most comprehensive login system available. All facets of the login system can be controlled at runtime so each customer can configure it to their own needs and policies. 

• These features include;
  • No logins at all - Users can choose to make the system loginless.
  • Passwords are stored as Salted-Hashed values, not as encrypted text, in accordance with all current best practices.
  • Second Factor Authentication using SMS or Email with Customer Defined Policies. When to require the second factor is a crucial element here, with options including every time, only on new devices, or on a time-based system.
  • Active Directory support for those customers with an Active Directory server. This allows for password, or password-less login against an Active Directory server, and also an optional In-Group setting on the server. This gives Active Directory Administrators complete control over who can use the program.
  • Guest Logins (with pre-defined guest accounts) can be added. These have a user name, but no password, and usually have limited program access rights.
  • Customer-defined password policies allow each customer to determine the password requirements for their users. Interesting options here include the prevention of password-reuse, and also the unacceptance of passwords that are commonly used by people. (So no 1234 or password weak passwords.)
  • Customer-defined Lockout policies allow the user to determine when a user account will be locked (and for how long it will be locked) if multiple incorrect passwords are entered.
  • Password Resets via SMS or Email
  • Users can create new accounts (ie self sign-up) and be given default access rights.
  • multi-tenant support with either unique-user or company/user logins.

• Security Tables

• All sensitive information in the data tables are stored encrypted and cannot be altered (or deciphered) by unauthorized programs.
• Unencrypted fields are tamper resistant - editing them in an external program will make the data unusable.
• Tables make use a of 4-secret system meaning that data can be bound to a specific program, specific table, or specific customer.
• All secure information in the tables can be extended without changes to the file structure. This means that (for example) new security policies (and new settings) can be introduced and no file conversion is required.
• User data is stored encrypted, in conformance with various privacy laws.

• User Groups

User Groups are a convenient way to assign standard access rights to users. A group is given a set of "rights" and anyone who is assigned to the group inherits those rights. 

If a user is in multiple groups then they accumulate the rights for all those groups - as long as any one group has a right, then the user also has that right. 

It is possible to override the group rights at the user level, denying a right to a specific user, even if they are in a group that does have that right.

• Doors

A number of systems refer to an approach known as "Doors". In this approach a "collection" of procedures and controls is brought together under a single name. Users can then be assigned rights based on this name.

For example;

A door called "Salaries" is defined. Under this single umbrella access to the Salaries field on the Employee Form, the Salary column on several reports, and the UpdateSalaries procedure are granted.

Functionally Doors, and Groups are the same thing. Users who are assigned to a group get the rights for that group. By creating a group called Salaries, rights can then be assigned to that group. Employees who need access to those rights can be assigned that group.

Perhaps the most striking difference between Doors and Groups is that Doors are intrinsically defined by the programmer - they collect all the procedures and controls together under one name - which is then "locked in" at compile time. By contrast Groups allow rights to be more fluid, and can be created and maintained at runtime.

While moving the maintenance to runtime increases the flexibility of the system, it can also impose a higher load on the customer. Since they don't (yet) know all the places the Salaries occur in the system, they would find it burdensome to create and maintain these kinds of groups.

To overcome this limitation, programmers can pre-create groups, with specific rights. These groups can then be maintained by the programmer, and distributed with the program. These can then exist as a starting point for customers, and also be updated as the programmer adds more controls to the program.

• Users

A user, is, as the name suggests, a person who uses the program.  A user has a Login and a Password. In addition Email and Phone fields allow for second factor and password reset communications.

A user can belong to one or more groups, and can also be assigned their own rights that can override their group rights.

• User Levels

There are six possible levels for a user.

• No Level 
• Guest 
  • Same as an operator but logs in without a password.
• Operator 
  • Can be assigned to groups. Has limited access as set by a Supervisor or Administrator.
• Supervisor
  • Has unlimited access to the program.
    Can assign rights to Operators and Groups.
    Can not create, delete or edit, users or groups.
• Administrator 
  • Has complete access to the system, and can add, edit and remove groups and users from the system. They also control the runtime Secwin settings for the company they are in.
• SysAdmin 
  • Same as an Administrator, except has control over all the companies in the system. The first user in the database has to be a SysAdmin level user, and this user cannot be deleted if other users exist.

• Default Rights

Users of type SysAdmin, Administrator and Supervisor have access to all the program functions of their type. Users of Type No Access cannot access the application at all. For these users the Default Rights setting does not apply.

For Operator and Guest users you can set their default access rights. This is the right that will be assumed, if the right is not explicitly set on the group, or user level.

The possible options are All, Group or None.

If set to All then the user will have access to the whole program except for places where they have personally (or all the groups they are in have specifically) been set to No Access. This is the most permissive option and should only be used for users who have "almost Supervisor" levels of access.

If set to Group then the user will inherit their access from their Group(s), including the default access given to the group(s).

If set to None then only access rights explicitly assigned to the user, or to one of the groups the user is in, will be available to the user.

• Unlocking a User

If a user gets their password wrong too often they may be temporarily  or permanently "locked" in the system. In the temporary case they will be automatically unlocked after some period of time.

In the permanent case (or indeed in the temporary case) a use can be unlocked by a administrator by editing the user record, and clicking on the Unlock User button.

• Deleting Users

Because users appear in logs and so on, user records are not deleted. If you "delete" a user then they appear in the users list as deleted, and they can no longer log in.

A user can be undeleted by an administrator by editing the user record, and clicking on the Undelete User button.

• User Self Signup

In most desktop applications a user has to be added to the program, before they can log in. However in many web applications it is desirable for users to be able to add themselves to the system - usually with some limited set of functionality being offered.

As with most DEX features, this functionality is available in both Desktop and Web applications.

This feature is only available when using Program Login or Windows Login types. It is not available for programs using Active Directory authentication.

This feature is only available if either SMS or Email functionality is available in the program. (The initial password is sent to them using one of these options).

When a user clicks on the Register button on the login window, then they will be asked for a Login, their name, an Email address and Phone number. Once they have completed the form a new password is emailed (or SMS'd to them) so they can login.

• User Login Type

Using the Security Policies, it's possible to set the login type that the program will use. There are a number of options, including Program logins, and Active Directory logins.

In Active Directory systems it may be desirable to add additional users - ones not in the Active Directory database, but which need access to the program. It may also be desirable to have a SysAdmin user, who can log in without using Active Directory to avoid the login paradox.

Users can be set to have a specific login type (i.e. Program Login) even if the program is set to use a different login type. This is done on the Update User form, on the Other tab. 

• Runtime Settings

Security is always a balance between security and convenience. The higher the security level, the more inconvenient it is. Each customer will have different needs and will find this balance in a different place.

A key aspect is the ability to configure Secwin at runtime so that each of your customers can apply the features and policies that they prefer, and thus balance their security needs against the inconvenience they are prepared to tolerate.

To configure these settings a user has to be User Level of Administrator, or SysAdmin.

• General

SMS Available: Tick this option on if your program has the ability to send SMS's. If this option is on then SMS can be used as a second factor option, or as a way for user's to reset their own passwords.

Email Available: : Tick this option on if the program has the ability to send Emails. If this option is on then Email can be used as a second factor option, or as a way for user's to reset their own passwords.

• Login Policies

Login Type: Select the Login method that the program should use.

• No Login
  • If this is chosen then no user login screen will be presented to the user. The user will automatically be logged in as an SysAdmin.
• Program Login
  • The user will log in with a username and password. These will be stored locally in a database.
• Active Directory Login (Get username and password)
  • The user will enter a login and password, this will then be validated against an Active Directory server. Once inside the program groups and rights are assigned as normal, and this information is stored in a local database.
    
    Generally speaking, the existence of at least two SysAdmin users is a good idea. If the ability for one of them to login is lost, then the other can be used to restore the first one to working order. When using Active Directory authentication the use of one local user is recommended in case the Active Directory credentials are changed unexpectedly.

• Active Directory Login (User Name from Windows)
  • The Windows User Name will be checked against the Active Directory server. No password to the program is required.
    Once inside the program groups and rights are assigned as normal, and this information is stored in a local database.
    
• Windows Login
  • The Windows User Name will be used, no password is required. Once inside the program groups and rights are assigned as normal, and this information is stored in a local database.

Default User Name From Windows: Prime the User Name field with the Windows user name.

Allow Remember Login: Allow the program to remember the user who is logging in, and store that for future logins.

Tokens Expire After (days): The number of days that auto-login-tokens are good for. If set to 0 then the tokens do not expire.

Allow Guest Login: Allow the user to login using a Guest account.

• Lockout Policies

This policy can automatically lock a user account if brute-force logins are detected. You can set how long the lockout is for, and how many incorrect passwords will trigger it. When a valid login occurs then the lockout counter is reset to 0. If  a user is locked, then they can be unlocked by an administrator in the program. The administrator does this on the update user screen in the program, by clicking on the Unlock User button.

Lockout Type:

• None: Users are not locked out, regardless of password fails.
• Temporary: Lockouts are temporary and expire after a certain amount of time.
• Permanent: Lockouts are permanent. A user must be unlocked by an Administrator before they can log in again.

If Incorrect Password: The number of incorrect passwords allowed (in the time specified) before the user will be locked out.

Times in: The time period being monitored. If, for example, this is set to 12 hours then the failed counter will reset after 12 hours. If this is left blank then there is no limit to the time between fails.

• Password Policies

Passwords are always Case Sensitive.

Password policies are often set by the customer against their specific set of rules. Interestingly these policies often weaken passwords rather than strengthen them. Nevertheless they may be required for various reasons.

Minimum Password Length: : Longer passwords are better.  However requiring passwords that are too long can hinder rather than help security.  There is no limit to the password length in Secwin (although allowing this to be set to greater than 256 characters will require the entry field on the Login Window to be made bigger.)

Password Expiry Days: Force the user to change their password after some fixed number of days. Use of this option will weaken security. 

Do not allow common passwords: Tick this on to prevent users from using a password that is commonly used. A list of the hundred thousand (100 000) most common passwords is shipped with Secwin as CommonPasswords.Txt. This file should be included in the same folder as the EXE. This is a very good option to have on.

• Password must contain one or more digits
• Password must contain one or more uppercase characters
• Password must contain one or more lowercase characters
• Password must contain one or more special characters

All of the above are self-explanatory, but do nothing to improve security. Use them only if local (bad) policies require them.

Do not allow users to recycle passwords: If this is on then users will not be able to reuse a recently used password. In places where mandatory password expiry is set this prevents a small number of passwords from simply being rotated. (This is a good policy if you are expiring passwords.)

User Password Self-Reset Method: If Email or SMS are available then you can allow users to reset their own passwords (without knowing the current password.)

Setting this option to Not Allowed means that an Administrator will be required to reset the password for the user, on the Update User screen.

Be aware that both SMS and Email can be compromised though so allowing users to reset their own passwords (without knowing the existing password) can be a security risk. Requiring an Administrator to reset the password is more secure, but brings another human into the loop and communication of the new password to the user still has to happen securely. Either way it is recommended that the user change their password, after logging in, the first time the password is used.

Note 1

 https://www.enzoic.com/surprising-new-password-guidelines-nist/
https://pages.nist.gov/800-63-3/
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf

Note 2
https://www.microsoft.com/en-us/research/publication/do-strong-web-passwords-accomplish-anything/

• Second Factor Policies

Access to any system can be achieved using one, or more, of three different items.

• Something you know: This is the most common. The password is a "secret" in your head. It's effective as long as this secret remains secret. This approach works best when the user is making use of a password manager (which assists with passwords never being reused for two different programs or services.)
• Something you are: This is biometrically linked to you, for example a fingerprint, voice print or face recognition. The quality of these systems vary somewhat but generally they provide good security.
• Something you have: : This makes use of a phone, or email, or other device which you control. This approach remains effective as long as you have control of the device.

DEX supports logins that make use of two-factor authentication, in other words it allows you to login with a password, and/or email/SMS. This approach though can be tedious to use every time so several policies control how this behaves.

Note that use of this feature implies that your program supports the sending of Emails or SMSs. If you do not have this facility in your program, then you cannot make use of Second Factor Authentication.

• Second Factor Authentication
  • Not Available: This is set if you don't want to allow second factor authentication, or Email and SMS are not available in your program
  • User Optional: the user can determine if they want to use Second Factor or not
  • Required (Either SMS or Email): Second Factor logins (at least some of the time) are required to use this program. Either SMS or Email could be used for this.
  • Required (Both SMS and Email): Second Factor logins (at least some of the time) are required to use this program. Both SMS and Email will be used for this, the user must have access to both for the login to work.

• Trigger Second Factor When
  • Always: The second factor is triggered on every login.
  • On New Machine: The second factor is only triggered when the user logs in from a new machine.
  • On Password Change: The second factor is triggered when the user uses a new password for the first time.
  • Every n Days: The second factor is triggered on a regular basis, like once a week and so on.

All the above options can be used independently. In other words the customer may require second factors to be used on a new machine, and also when passwords change.

Stale Time: : Second factor authentication works by sending the user a one-time code to their email, or SMS device. This code is generated, and sent, while they are logging in. (This can delay the login process until the code is received.) However the code itself should become "stale" at some point - in other words they need to use it within a time (typically a few minutes) of generation. A good option here would be 15 minutes or so.

• Active Directory

These options are only visible on the settings form, if the Login Type is set to one of the Active Directory options.

In this context the word Directory has nothing to do with Folders on the disk. Rather it refers to a central user directory which allows administrators to control computer use from a remote location. Active Directory uses a technology called LDAP and Secwin (via NetTalk) supports LDAP. The most common Active Directory in use is the Windows Active Directory Directory Services.

There are two approaches to using Active Directory;

1. The user enters a login and password as usual. Instead of being validated against a local database though they are passed to the Active Directory Server and validated there. In addition to this the user has to be placed in an Active Directory Group in order to gain access to the program. This allows a remote administrator to control access to the program - for example terminated employees can be removed from the group centrally, instead of having to visit all the different programs individually.

2. The program passes the Windows User Name to the Active Directory Server. The server then checks the group to see if that user has access to the program.  The user does not (and can not) enter the user name, and there is no password required. This approach assumes that logging into the machine itself, as a valid user, is sufficient authentication. This is also sometimes known as single-sign-on. This approach can be used in conjunction with Second Factor Policies to improve security. This approach is only supported in Desktop programs, not Web programs.

In order to make use of an Active Directory server, some settings are required. You will need to liaise with the customer's IT department to get these settings.

Active Directory Server: These details allow the program to connect to the server itself.

• Host: (required) This is the address of the server. This could be an IP address, or a DNS (or WINS) name that resolves to an IP address.
• Port: (required) This is the port the server is running on. The default port for Active Directory connections is 389 (for insecure) or 636 (for secure).
• TLS: Tick this on if the connection to the server should occur over TLS.
• Domain: (required) This is the domain, on the server, in which all the users, and groups exist.
  
  NOTE: If one of the required fields above are not set, then the program will be unable to validate against the Active Directory server. In this situation a user (if they have a level of Administrator or higher) will be logged in (without checking) primarily so that the Administrator can correct the settings.

Active Directory Admin User / Password: These are the details for an Admin user - one that allows you to make requests to the server to check if a user is in a group.

NOTE: If these are not set then the user logging in (if they have a level of Administrator or higher) will NOT be checked against a Group, even if the Active Directory Group name is set.

NOTE: If these fields are set, but either the user name, or password, is incorrect, then the user logging in (if they have a level of Administrator or higher) will NOT be checked against a Group, even if the Active Directory Group name is set.

Active Directory Rights: This is the name of the Active Directory Group, that the user must be a part of, in order to gain access to the program.

• User Self Signup

In most desktop applications a user has to be added to the program, before they can log in. However in many web applications it is desirable for users to be able to add themselves to the system - usually with some limited set of functionality being offered. 

As with most DEX features, this functionality is available in both Desktop and Web applications.

This feature is only available when using Program Login or Windows Login types. It is not available for programs using Active Directory authentication.

Allow Self-Signup of new users: If this option is on then a REGISTER button, or link, will appear on the Login screen.

Group for Self-signed-up users: Select a group here that the new user will automatically be placed into. the new user will have the level of Operator. By controlling the access rights of this group you effectively control the access rights that self-signed-in users will have. Once signed up an Administrator can assign the user into other groups, change their rights, and so on.

• Multi Tenant

Default Record: This is ticked on if this is the default settings record. In a single tenant situation there should only be a single record in the settings table, and this field should be checked.

Company: The name of the company that uses these settings. The value in this field needs to be unique. In multi-tenant situations the company name is used to distinguish between tenants. when users log in they will need to identify the company they are logging into.

PIN: A PIN code identifier for the company.  The value in this field needs to be unique. The use of PIN codes allows users, in a multi-tenant setup, to easily identify the company they are logging into (without needing the whole company name). It is most useful in situation when displaying a list of companies, and asking the user to select the correct one, is not desirable. 

• Logins

One key feature of Secwin is that it allows you to create (or more likely import) a login window for your application. While at first glance this should be a trivial feature, there are a lot of login flavors, and this can make the procedure quite complicated. Secwin is designed to support a whole range of optional login features, and at the same time allow your customers to choose which of those features they would like to make use of.

• Login Procedure

The start of each application is the login window. While the cosmetics of the window can be altered, functional changes to the window should be applied with care.

• Change Login

If this window is called, and the login fails, or is cancelled, then the current user remains logged in.

• Logout

A Logout exists to call the Logout procedure.

Important: The Logout function deletes the Remember Login Token. So if a user (who is remembered) wants to not-be-remembered-anymore then they can do so by clicking the Logout button.

• User Changing Their Password

When a user is logged in they are able to change their password by going to the Change Password procedure. 

The user will need to enter the old password, and a new password.

The new password will need to conform to the Password Policies.

• Current User

A global object called Current User is created by the global template. This object is updated when the logged-in user changes.

• Remembering

One of the settings that the end-user can choose to activate is allowing a user login to be remembered.

This makes sense when the user is accessing the program from their personal computer or device, and where the penalty for someone else logging in as themself is limited. Of course if a different person gets access to the device then access to the program is compromised.

• Note 1 By default, on the desktop, the token is simply stored in the INI file. The token is bound to the machine (and the program) so "stealing" the token has no value. There can only be one token stored per machine per user.

On the web the token is stored as a cookie. It can be erased by the user simply by clearing their cookies (or by clicking on Logout). The browser usually protects cookies, as long as the connection to the server is secure (ie using TLS). These tokens are not bound to the device though, so should be used with care. In both desktop and web cases, if the user expressly logs out  then the token is deleted on the server, and the client,  and thus any (client side) copies of the token become useless.

Tokens have an expiry date - by default 30 days. This is one of the settings set by the SysAdmin when setting the Runtime Settings. Setting the expiry days to 0 means that the tokens do not expire.

• Note 2 The user login and password are NOT stored in the token. So if a user changes his password, or has his user login changed, this does not invalidate the token, and remembered logins will still work.
• Note 3 The name and location of the INI file is specified on the Secwin Global extension, Options tab.
• Note 4 Remembering is only in play for the Program Login, and Active Directory with User and Password login types. Logging in using the Windows login name bypasses the need for a user and password, and hence bypasses the need for a remember token.

• The Login Paradox

The system is setup by Administrator, or SysAdmin users. In order to login, a user has to meet all the requirements of the system. If the system is set such that it cannot validate any Administrator or sysAdmin user, then no-one can login to fix the system setup.

When the program is first installed, no users exist, so the user is logged in as a sysAdmin. However if users already exist, and the Admin user can no longer login, then  how can the settings be corrected?

For example, say the program is set up to use Active Directory authentication. This requires that the program be set up to communicate with the Active Directory server (server name, port number etc). What happens if those settings are, or become, invalid. How then to log in to correct the settings. A solution to this is to create a SysAdmin user who uses local credentials, not Active Directory credentials.

Generally speaking, the existence of at least two SysAdmin users is a good idea. If the ability for one of them to login is lost, then the other can be used to restore the first one to working order. When using Active Directory authentication the use of one local user  is recommended in case the Active Directory credentials are changed unexpectedly. 

• Setting Security Rights

Logging into an application is and important thing to do, but within the application the customer may want to limit functionality for users, based on what they are allowed to do. One of the goals of Secwin is to allow end-users to do this in an intuitive way, but a way that allows them to understand what a user's rights are, and how to set them.

A user has to be the level of Supervisor, Administrator or SysAdmin in order to assign rights to individuals or groups.

• Groups

DEX allows User Groups to be created. A user has to be at least at the Administrator Level in order to create groups.

Using Groups is useful because rights can be assigned to groups. Then when a new user is added to the system it is not necessary to set all their rights individually, you can simply assign the user one or more groups.

If a user is a member of more than one group then they get the access rights of all the groups. So as long as they have access to something through at least one of their groups, they will have access to that something. In technical terms access rights are OR not AND.

When a group is created you can set its access rights to default to either ALL or NONE. If set to ALL then the group has access to everything (by default) and it can be edited to restrict specific access. If set to NONE then specific access has to be granted to the group.

• Users

A user has to be at least at the Administrator Level in order to add users. (With the exception of systems which allow users to create themselves, more on that later.)

In addition to being in a group a user can have specific rights which override these group rights. These allows the administrator to not just to allow specific users to do specific things outside of their group, but it also allows the administrator to prevent a user doing something, even if their groups are allowed to do it.

Users who are not part of any group can also have their rights set on an individual basis.

When a user is created you can set their access rights to default to either ALL, GROUP or NONE. If set to ALL then the user has access to everything (by default.) This can then be edited to restrict specific access. If set to GROUP then the default rights of their group(s) are used. If any are set to ALL then the user's default is ALL, if all are set to NONE then the user's default is NONE.

• Run Time

There are two approaches to controlling the access rights of users at run time.

• Go to the window that needs protecting
• Press the system-wide Hot Key (Ctrl-F8 by default)
• Edit the rights for users and groups for that screen
• This approach is ideally suited to the less-technical supervisor. They do not need to understand the bigger application, they simply go to what they want to protect, and protect it. It takes slightly longer to do it this way, but can be done with minimal user training.

1. Make use of the Global "Set Access Rights" window. This window presents a lit of all the procedures which can be protected, and allows the supervisor to set the rights for all the procedures, and controls in one place. This approach is faster, but the user needs an understanding of how the application is arranged, and what procedures refer to what functions. 

• Bubbling

Menu Items and Buttons are often set to "Call a Procedure". Having the button present, but going to an Access Denied message is not very friendly.

The solution for this in Secwin 6 and earlier was to protect both the button in the calling procedure, and the destination procedure as well. this can duplicate work when setting up the system.

DEX  introduces the concept of Bubbling - if a user does not have access to a procedure then buttons and menu items that call that procedure (using the template Actions setting) are automatically hidden.

• Additional Program Restrictions

Disabling, and Hiding of controls for access control purposes does not happen in isolation. There may be other considerations which also come into play.

• Multi-Tenant

Multi-Tenant support is optional. It is more likely to occur in a web context than a desktop context. You can design a system to be single-tenant, and expand it to be multi-tenant later if you so wish.

• Introduction

In a Multi-Tenant situation multiple distinct groups of users exist. These groups are known as Companies. Before the user can login they (may) have to first identify which company they are logging in to.

Each company will have a record in the Settings table. In a single-tenant case a single record will be created in the table. One of the records (or the only record) in the table will be a designated "Default Record" and this in turn will be the default values for any other companies that are added to the list.

Users and User Groups belong to a specific company. If a user wants to access multiple different companies they will need to be added to multiple times (and will then exist as distinct users)

• Company-And-User versus Unique-User

There are two ways to identify a user.

• Company-And-User

In this approach the user name and company together are unique. This approach allows for multiple different users to exist, with the same user login - as long as they are for different companies.  So two customers could each have a user login (called say Humperdink), but since the company is also captured during login it is clear who is logging in.

This approach is more flexible, but does REQUIRE that the user identifies which company they belong to. (This may be active, as in selecting from a list, entering a PIN code or passive - like by using a specific URL.)

If the system is single-tenant then that company is assumed, and the user does not need to identify the company.

• Unique-User

In this approach the user name must be unique across ALL users in the DEX database, regardless of which data set they will be accessing.

If Humperdink already exists for one tenant, then another tenant may not also create a user called Humperdink. This is not a huge issue for people related login names, (people can be very creative with their login names) but it can become an issue when more generic names would be used. For example Administrator or Sales or other generic titles like that.

Login names in this situation are unique, so there is no need to select the company during the login process - since the user is unique, and the user is assigned to a company, the company is known when the user name is entered.

In Self-sign-up  situations it would still be necessary to determine which tenant the user was signing up for. Again this might be via selection from a list, PIN code, or URL.

Note: In this approach if a new Settings record is created (ie a new Company) then a new user MUST be created at the same time to login to this company. If no user exists for a company, then it's not possible to log-in to that company.

• Login Procedure

If multiple tenants exist, and the Company-And-User approach to login names is being used, then the user will need to identify their company in the Login procedure.

This is done via a Browse Control on the Company tab.  The goal of this control is to set the Login field to the value that the user selects.

This approach is easy for the user, but does show the user a list of tenants. In some cases this may not be desirable. If this is a problem then entering a unique PIN code for the company can be used instead. This PIN code is set by the SysAdmin user when creating the company. A PIN field exists on the tab, and can be unhidden when the Browse control is deleted.

• Multi Tenant <> Distinct Data Set

While it is probable that each tenant will have a distinct data set (ie in a different database, or different TPS folder) the two concepts should not be conflated.

Having multiple tenants does not imply multiple data sets. And multiple data sets does not imply multiple tenants. It is possible to have multiple tenants sharing the same database, and it's possible for a single tenant to have multiple data sets.

Managing multiple data sets is a completely different task to program access control, and so it falls outside the scope of what Secwin provides. It should in turn be compatible with any dataset-manager that you use.

• SysAdmin User

If a user has the user access level of SysAdmin, then they are able to manage the multi-tenant setup. They are able to create new tenants - create users, and groups, for tenants, and generally maintain the access rights - across all the tenants.

A SysAdmin user is assigned to a specific set of settings and policies, (such as password requirements) and these will apply to her.

A SysAdmin has access to the Browse Tenants, and from here can create new tenants, as well as users and groups for those tenants. In most cases when creating a new tenant, users will need to be created as well (at the very least an Administrator user for that tenant so they can add more users and groups)

In the Browse Tenants a COPY button exists to allow you to copy settings from an existing tenant when making a new tenant. This will copy the Settings, and Groups (including Group Access Rights).

When accessing the Set Access screen, a SysAdmin will see the settings for all the groups, and all the operators/guests for all the tenants.