Security Considerations

This help file applies to an out-of-date version of MainBoss.
The most recent version of MainBoss is MainBoss 4.2.4.
This help file does not exist in MainBoss 4.2.4, but the index for that version can be found here.

< Previous section  |  Table of Contents  |  Index  |  Next section >

Before proceeding to configure your MainBossWeb web site, you must make some decisions about security. This section discusses various factors that you should consider.

Depending on your ways of working, especially with cell phones and similar devices, you may find you have to sacrifice some level of security in order to get anything done. You may decide this means you won't use cell phones with MainBossWeb; alternatively, you may decide to live with reduced security or other complications. Thinkage takes no responsibility for any problems you may encounter if you opt for reduced security.

Web Requests: In order to use the Web Requests module, users must type in their email address and send it to the MainBossWeb web page. There are two possibilities:

• If you will only accept requests from people in your local Active Directory, then you must set up your MainBoss Service configuration accordingly. In particular, you might use the Automatically Create Requestors From Active Directory option.
• If you will accept requests from people outside your Active Directory, then you must enable anonymous authentication as described in Authentication Settings. In this case, anyone who can access the web page is authorized to type in an email address and submit it. Processing only continues if the email address is authorized to submit requests.
  
  If you do not have the Web Requests module, you do not have to allow anonymous authentication to this particular facility.

Web Access: In order to use the Web Access module, your MainBossWeb web site must be able to authenticate people as Windows users on the system where the web site runs. This means that people must enter their Windows login names and passwords.

The safest way to do this is to use ASP.NET's integrated Windows Authentication. When users attempt to use the Web Access module, they will be asked to send the login names and passwords, which will be securely encrypted when transmitted to the MainBossWeb site.

Unfortunately, integrated authentication does not work with some cell phone and PDA services. Whether or not the device itself can handle encryption, the service provider may use proxy servers that do not support integrated authentication. (This may mean that the device works fine when connected to your own Wi-Fi network but not when connecting through the device's usual service provider.) The symptom of this is that you aren't asked for your login name and password; you simply get a "permissions denied" message.

If the cell phones or PDAs that you intend to use can't handle integrated authentication, you must consider your options.

• One choice would be not to support access through these devices—users would only access MainBossWeb through networked computers or through handheld devices that do allow integrated authentication.
• The other choice would be to use "classical" authentication. If you go this route, you have two further options:

• Using SSL (Secure Socket Layer) or TLS (Transport Layer Security). Users will access the MainBossWeb web site with https rather than http, as in
  
  https://www.ourorg.com/MainBossWeb
  
  If the device supports this facility, login names and passwords will be encrypted when transmitted.
  
  In order to take this approach, IT personnel will be required to set up SSL/TLS access, which includes the use of a security certificate. See below for more details.
• No encryption. In this case, login names and passwords will be sent in plain text through wireless connections. This leaves you seriously exposed to wireless eavesdroppers, and is therefore not recommended.

Security Certificates: A security certificate may be obtained from a trusted Certification Authority (CA) or may be self-generated. Large organizations often have a CA certificate already, in which case the same certificate may be used for MainBossWeb.

You can create your own self-generated security certificate using the IIS 7 manager. (See Initial Set-Up of this guide for a reference on how to start the IIS manager.) Once you've started the manager, click the entry for the server in the left-hand panel, then click Server Certificates in the IIS section of the middle panel. In the resulting window, click Create Self-Signed Certificate (in the right-hand panel) to create a self-signed certificate.

If you use a self-signed certificate, devices using https to connect to your MainBossWeb web site must be told to trust this certificate. Note that most browsers display strong warning messages when a user first tries to connect with a web site that has a self-signed certificate; therefore, users must be reassured that connecting with your site really is secure. Usually, this is only a problem for users outside your organization, since there are ways to tell all the computers on your internal network to accept a particular certificate.

If you are using SSL/TLS, make sure that your firewall allows such communications through. Typically, SSL/TLS use port 443, so the firewall should allow connections to this port (if you wish to open your web site to outside connections).

< Previous section  |  Table of Contents  |  Index  |  Next section >