Tech Tip 8 - Log in to Portal Automatically

h4. 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. A typical example is to display a dashboard or status page to a screen in a public lobby. While there are some specific mechanisms built in to certain parts of the portal to get such access, many pages 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.

This tech tip shows how a simple HTML page 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 need to be defined in GroundWork and potentially the A and A engine (for example LDAP). 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 browser and able to control mouse and keyboard.

Therefore you must 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)
* 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.

h5. Use GWME 7.2.1

This has been tested on version 7.2.1. There are no code changes on the installed Monitor. There will be configuration needed, in a standard way. The provided sample script will need adjustment to point to the proper GW Server and to use the proper User and Password.
{note}
Make very sure that the server name you supply is exactly what is in the GW installation and not an alias or other alternative name. It has to be the specific machine_hostname that you supplied at GroundWork install time.
{note}

h5. Create or choose user and role

In the 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

Again in GroundWork Monitor, as the root user,
* Navigate to each page you wish to make accessible and add the permissions for the chosen Role to
** page properties, from top level downward
** container properties
** application properties

h5. Get and modify the script

<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://{color:FF000C}localhost{color}/josso/signon/usernamePasswordLogin.do" method="post">
<input type="hidden" name="josso_cmd" value="login"/>
<input type="hidden" name="josso_back_to" value="http://{color:FF000C}localhost{color}/portal/initiatessologin"/>
<input type="hidden" name="josso_username" value="{color:FF000C}user{color}"/>
<input type="hidden" name="josso_password" value="{color:FF000C}password{color}"/>
</form>
</body>
</html>
{note}

h5. Distribute the script to the workstations or users

Users can keep the script in a local file system, and execute it from their browser. 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

{tip}
open -a "Google Chrome" ./script.html
{tip}

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|mailto:[email protected]].