Tech Tip 8 - Log in to Portal Automatically
Tech Tip 8 (12/04/2018) - How to access GroundWork Portal without personal login
Occasionally you may find a need to have a log in to the portal which does not require that a person initiate the process with a user name and password, for example to display a dashboard or status page to a screen in a public lobby. Many pages in the GroundWork Monitor portal depend absolutely on browser access using a token obtained through the Single Sign On application. SSO Authenticates and Authorizes the session based on proper User name, Password, and previously assigned Role, and integrates with LDAP or Active Directory.
Considerations
This tech tip shows how a simple HTML script can be executed from a browser session, providing the User name and Password to the standard login page. As with any login, this requires that the User and Password as well as the assigned Role be defined in GroundWork (and potentially the A and A engine, for example LDAP) beforehand. Once the HTML script is executed, the browser will open to the landing page associated with that User's Role, and any actions permitted to that Role, including page navigation, will be available to whomever is in front of the the machine and able to control mouse and keyboard.
You must, therefore, be extremely careful about implementing this tech tip. Secure Single Sign On is a primary design goal and feature of GroundWork Monitor. This tech tip method defeats or weakens the mechanism if not carefully controlled. The security risks are manifest:
- Deploying it on an unsecured workstation means you do not know who is using it.
- The Portal Landing Page must be chosen as one that is safe for all eyes (default is the Summary page. See How to change the portal page navigation for more info.)
- Control of the selection of permitted pages, containers and applications for the specific Role assigned is critically important and must be reviewed and tested regularly.
- Anyone with command line access to the workstation or server where this script is deployed may possibly read the text content of the script and learn the user name and password, as well as the GW Server name, thus making it possible that they could run the script from some other workstation.
- It is advisable to configure the GW Server Apache web server to accept connection from IP addresses or ranges on an exclusive basis to reduce the target footprint.
- The session token obtained and used for this purpose will have the same expiration characteristics and limitations as any regular user's token. Therefore deploying this you must consider how you will reinitiate running the script when the token is invalidated for one reason or another.
Requirements
Use GWME 7.2.1
This has been tested on version 7.2.1, with appropriate patches. There are no code changes on the installed GroundWork Monitor. The provided sample script will need adjustment to point to the proper GroundWork Server, and to use the proper User and Password.
Using this script
Create or choose user and role
In GroundWork Monitor, as root or admin user:
- Create a Role for the purpose and assign the resources, host groups, and service groups that you wish to expose to this mechanism.
- If you are using local, Monitor-based Authentication:
- create a Group and associate it with the Role
- create a new User which will be the actor in this script, assigning the User to the Group you created and assigning a password
- Conversely, if you are using LDAP:
- create the User
- create the Group and assign the User to it
- edit the /usr/local/groundwork/config/ldap-mapping-directives.properties file to associate that Group with the previously created GW Role
See System Administration How To's for more information.
Get and modify the script
Attached is a sample script, repeated here with the four places you would need to change shown in red:
 | <html>
<body onload="login();">
<script type="text/javascript" language=JavaScript>
function login() {
document.cookie = "CGISESSID=;path=/;expires=Fri, 3 Aug 1970 20:47:11 UTC";
document.cookie = "PHPSESSID=;path=/;expires=Fri, 3 Aug 1970 20:47:11 UTC";
document.cookie = "nagvis_session=;path=/nagvis;expires=Fri, 3 Aug 1970 20:47:11 UTC";
document.cookie = "treeArrayC=;path=/nms-rstools/php/rstools/;expires=Fri, 3 Aug 1970 20:47:11 UTC";
if (window.document.forms && window.document.forms.length == 1) {
window.document.forms[0].submit();
}
}
</script>
<form action="http://my-groundwork-server/josso/signon/usernamePasswordLogin.do" method="post">
<input type="hidden" name="josso_cmd" value="login"/>
<input type="hidden" name="josso_back_to" value="http://my-groundwork-server/portal/initiatessologin"/>
<input type="hidden" name="josso_username" value="user"/>
<input type="hidden" name="josso_password" value="password"/>
</form>
</body>
</html> |
Be sure to use the exact same hostname in the script that appears in the address line when you are logged in normally. For example, if your GroundWork Monitor hostname is using the short DNS name, use the short name here, not the fqdn, or vice versa. Make sure there are no spaces at the start and end of the username and password, and avoid using escape character like | or * in the password field.
Distribute the script to the workstations or users
Users can keep the script in a local file system, and execute it from their user interface (e.g. double-click on a desktop icon). For automated execution, for example without a keyboard or touch screen, one could use a scheduler to trigger the browser from command line. On a Windows workstation which controlled a lobby big screen you might use the AT scheduler to initiate a new session every 8 hours (matching the default portal timeout of 8 hours)
Here is an example of running the script from command line on a Mac
 | open -a "Google Chrome" ./script.html |
Bear in mind that local conventions you set up for your browser (like remembered passwords/logins) will affect the second through N executions of the script.
Questions? Problems? Let us know at GroundWork Support.