Rescue:Single Sign On
In the world of enterprise IT, many companies end up with multiple, disparate systems that all require their own separate authentication. This proves to be a challenge for both the administration of accounts, and also for the end user having to remember all the different authentications. LogMeIn understands these challenges, and we have developed technology to help you reduce this issue. LogMeIn Rescue now supports Single Sign On (SSO) capabilities. This guide will outline the issue at hand, and give you the ability to remove the need for another login from your environment.
As you can see, even in the most basic environments, technicians have at least two systems to log into in order to do their job. In most enterprise environments, the average number of independent systems a typical user is required to log into is between three and four. As the enterprise infrastructure becomes more complex, the network administrator is required to manage an ever-increasing number of user accounts for each individual user, exponentially increasing the administrative workload per system. The progression of user sign-on in this scenario would be:
- User logs on to Windows
- If successful, user is given Domain access
- User visits LogMeIn Rescue site and logs on.
- If successful, user is granted access to Tech Console (or My Account if they are an account Administrator)
In this scenario, the company hosts a piece of code on their intranet site that will automatically log the technician into their LogMeIn Rescue account and initialize the Rescue interface. Since the company is hosting the code, it has free reign over what systems the technician automatically authenticates to. Examples would be Active Directory, LDAP, Apache Directory Services, etc. The progression of user sign-on in this scenario would be:
- User logs in to Windows
- If login is successful, the user is granted Domain access
- User visits the company intranet site
- When clicking the link/button/etc to launch Rescue, the intranet uses the SSO code to authenticate them to Rescue, and direct them to the Technician Console (or My Account if they are an account Administrator).
The value and efficiency of this process is that the user is only required to remember one set of authentication credentials - their Windows Domain username/password. Moreover, the system can be customized to authenticate the user against virtually any other system, as long as the SSO code is customized to use that system.
Technical Implementation Overview
The SSO functionality makes use of the API technology Rescue offers.
- Company hosted script makes an HTTP request to the SSO login services.
- SSO login service returns success + URL, or error message upon failure.
- Company hosted script then evaluates the returned value.
- If successful, company-hosted script redirects the user to the URL provided, or if unsuccessful, error handling is triggered.
SSO URL = https://secure. logmeinrescue.com/SSO/GetLoginTicket.aspx SSOID = The ID you define in Tech’s properties in the Admin Center CompanyID = See the SSO code example in Admin Center > Settings Password = SSO password defined in Admin Center > Settings
An example of this formatted URL would be:
When making this request, the SSOID, CompanyID, and Password are sent to the Rescue SSO service, which returns a string value. A successful authentication would return a string similar to:
An unsuccessful authentication would return a string similar to:
ERROR: INVALIDPARAMETERSERROR: INVALIDSSOID
You can then process this string, process for errors, and handle them accordingly. In a typical scenario, you would use an IF condition to process the returned string, and check for the presence of OK:” in the first three characters. If they are present, you would then take the URL (the last part f the string you processed) and either present it to the user, or redirect them automatically. This s exactly what the example in the Admin Center does.
Since Single Sign On requires a user ID to be authenticated, the logical step here is using Windows credentials. Most programming languages allow you to do this with server side variables, but the key river in doing this is that the server connection needs to be an authenticated one (not anonymous). his is an integration process through Internet Explorer, which would pass Domain credentials to the intranet server automatically, provided you don’t allow anonymous access. The best approach is to assign the authenticated user ID from your Intranet web server to the SSO service as the SSOID.