Setting up Single Sign-On Authentication
Using Single Sign-on, support technicians can securely log in to LogMeIn Rescue from other applications.
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 administrators and end users. LogMeIn Rescue's Single Sign-on (SSO) capability helps you manage this issue.
Setup takes place in the Administration Center on the Global Settings tab under Single Sign-On.
You have control over how technicians and administrators can log in to Rescue.
Here is a summary of options available under :
- Option One: Standard or SSO
- Users will be able to login with either their standard Rescue email/password or their SSO ID. Both methods are valid.
- Remember: When allowing SSO you must set a Master SSO password (on the Global Settings tab) and assign an SSO ID per user (on the Organization tab). Users without an SSO ID are unable to use SSO.
- Option Two: SSO only
- Users will be able to login using their SSO ID only. With this option, users without an SSO ID will be unable to login.
- Remember: When allowing SSO you must set a Master SSO password (on the Global Settings tab) and assign an SSO ID per user (on the Organization tab).
- Option Three: SSO only plus Allow users without an SSO ID to use standard login
- Users with an SSO ID will be able to login using their SSO ID only.
- Users without an SSO ID will be able to use standard login.
How it Works
SSO functionality makes use of API technology.
- The company-hosted script makes an HTTP request to the SSO login services
- SSO login service confirms the successful login and retrieves the login URL, or an error message upon failure
- The company-hosted script then evaluates the returned value
- If successful, the company-hosted script redirects the user to the URL provided, or if unsuccessful, error handling is triggered
The HTTP request is a simple formatted URL string, which contains the SSO URL, SSOID, CompanyID, and SSO Password.
- Single Sign-on URL (SSO URL)
- For logging in to the web-based Technician Console: https://secure.logmeinrescue.com/SSO/GetLoginTicket.aspx
- For logging in to the Desktop Technician Console: https://secure.logmeinrescue.com/SSO/GetDTCLoginTicket.aspx
- Single Sign-on ID (SSOID)
- The ID you define in the Single Sign-On ID box on the Organization tab of the Administration Center when adding or editing organization members.
- See the sample code on the Global Settings tab of the Administration Center.
- Master SSO Password
- The SSO password defined on the Global Settings tab.
An example of this formatted URL would be:In case of logging in to the web-based Technician Console:
In case of logging in to the Desktop Technician Console:
- x86 DTC:
- x64 DTC:
When making this request, the SSOID, Password, and CompanyID are sent to the Rescue SSO service, which returns a string value. A successful authentication would return a string similar to:
In case of the web-based Technician Console:
OK: https://secure.logmeinrescue.com/SSO/Login.aspx? Ticket=6ab9a0f6-d3ce-4f498-8ea7-b9a76a67a0c8
In case of the Desktop Technician Console:
- x86 DTC:
- x64 DTC:
An unsuccessful authentication would return a string similar to:
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 of the string you processed) and either present it to the user or redirect them automatically.
Single Sign-On: Considerations
Since Single Sign-on requires a user ID to be authenticated, the logical step is to use Windows credentials. Most programming languages allow you to do this with server-side variables. The key driver is that the server connection needs to be an authenticated connection (not anonymous). This is an integration process through Internet Explorer, which would pass Domain credentials to the Intranet server automatically, provided you do not allow anonymous access. The best approach is to pass the authenticated user ID from your Intranet web server to the SSO service as the SSOID.
Single Sign-On and SAML 2.0
LogMeIn Rescue is compatible with Security Assertion Markup Language (SAML) 2.0. For detailed information about configuring LogMeIn Rescue to use SAML 2.0 with your Identity Provider, see the LogMeIn Rescue Web SSO via SAML 2.0 User Guide.