TN 2884: Fully Authenticated KeyReporter
Secure KeyReporter so all users must log in to access the web interface
Overview
System and data security is increasingly important. In order to protect your information, you may want to not allow guest access to KeyReporter. This article talks about how you can do this while still easily allowing authenticated access to your users. Using this guide you can provide the same service, and indeed more customized settings if desired, while increasing system security. Consider that if you Embed KeyReporter objects in other websites, disabling Guest access will cause that to stop working. You may consider a hybrid approach in such a case, where Guest has very limited features and users must log in to see more options and data.
Disable Guest
In KeyConfigure -> Windows -> Admin Access open up the KeyReporter Guest Account and uncheck the "Account is enabled" box. This will force hits to the website to go to the login page.
Set up External Authentication
If you have not already, the next step is enabling Admin Authentication. The term comes from years ago when any authenticated user of our software was considered an Admin as opposed to a Guest or Client. However, an Admin account can simply be a Guest level and have no Administrator level rights at all. Active Directory is the most typical solution, and many options can be referenced from the Authentication Modules documentation.
At the simplest, in a standard AD you can just go to KeyConfigure -> Config -> Admin Authentication and change the Method to Active Directory. No further configuration is needed in most cases, but in the interest of security we recommend enabling the option at the bottom for Disconnect inactive sessions and consider something like 30 minutes. The important setting here is the Unknown External Logins drop down. From this, choose Community. This is a built in account that has only Guest level access, just like the KeyReporter Guest that we disabled above. If you are on 7.7 or later, that's it, you're done.
If you are using a version prior to 7.7 that does not have this option, you will need to create a new account per the below steps and then select that in this dialogue. What this does is force any account that passes AD authentication, but does not have it's own External Account or External Group reference (another topic for more granular permissions to specific groups) to use the one account chosen. This prevents hundreds or even thousands of external accounts from being made in the server, and allows you to control the dashboard of all these users via the single account.
Create a new "Guest"
We now want to create a special reference account for most users to simulate the guest level of access while still requiring authentication. Right click on the Public Role and Duplicate it. You can call the copy something like "Authenticated Guests". By default it will have the Guest settings, but you can now fully customize how you want users to experience KeyReporter. The main settings of interest are at the bottom under KeyReporter Privileges. Some setting under other sections will also be relevant depending on what you want users to do. Some of these are self explanatory, other are a bit more obscure when you're not familiar with the deep features of the software, and some are not yet implemented. Please experiment with a test account to see how things interact, and contact support for questions and a deeper exploration of the options.
Next, right click in white space of the window and create a New Account. If this is an internal account you MUST set the password or it will act as if disabled. No one needs to know this password, but you can use this account directly for testing the behavior others will see. In the upper right of the web UI, the logged in user will see their account name, as opposed to the special shared account name. Drag the "Authenticated Guests" Role you just made into the Roles & Groups pane of this new account, along with the Viewers Group. The Group gives universal view access to all objects in the system just like a Guest. A more customized implementation could involve using a new group with custom ACL access on objects, or custom adding the Role you made to objects. That is much more labor intensive and granular, and again support will be happy to discuss any such scenario to help advise on settings. Layered with the Role which gives the privileges to go with the view access, we create a set of rich permissions.
Create the Dashboard
This step is optional. If you gave your external account "View Dashboard" privilege, you can set up the dashboard view you want everyone to have. If you left them with just View Maps, you can skip this step. Log in to KeyReporter as an actual Administrator as you normally would for management. Expand the Dashboards list and check if the account you made is listed. If so, select it. If not, select Guest as a starting point, go to the menu in the upper right of the ribbon, and Save Dashboard As the name of the account you made (not the role! e.g. "Students").
With this dashboard selected (shown at top of Dashboard list with an x beside it) you can now customize what you want these users to see. All changes are saved as you make them, so when done you can just close that dashboard by clicking its x.
Test
Please, test. Log in as a normal user from your domain to ensure that you see the name of the guest account you created in the upper right, the dashboard you may have created for this account, and can see all the maps you want them to see. Make sure there are no unwanted navigation features turned on. If there are, return to the "Authenticated Guests" Role you made and turn off the related privileges. Make sure you can do and see the things you want for the user experience, and turn on privileges as needed if anything is missing. As always we're happy to help if you get stuck in the details and can't find the combination you need.
As always please contact support if you need assistance.