Trusted Login Connector (Hosted SSO)

Trusted Login Connector (Hosted SSO)

Table of Contents Summary... 3 Frequently Asked Questions... 3 Architecture... 5 Installation/configuration... 5 2

Summary New functionality allows SelectHR users to sign in to hosted systems using their locally authenticated Windows credentials without requiring them to re-enter a user name or password. Optionally they may be required to confirm their password, in which case they will be prompted with their Windows user name and must enter their Windows password to be authenticated against their Active Directory. Frequently Asked Questions Q: How does the SSO authentication application work? A: The SSO component is a web application you would need to host on an internal IIS web server, configured with anonymous authentication DISABLED. This allows the application to determine the logged on user (REMOTE_USER variable). It is this component that verifies the logged on user, and generates an authentication ticket which is then reliably passed to the hosting application via https. Q: Do we need to install this component in a DMZ/perimeter zone? A: No. All communication is via the client s browser on your network and over the internet via https. The SSO component does not need to be in a perimeter zone requiring AD access or similar. It simply generates and returns authentication tickets to the client browsers which are passed to the hosted application. Q: We are implementing an ADFS solution for SSO with another Cloud implementation. Can this standard ADFS solution be used with the HRIS system? A: The SSO application is an on premise authentication solution, and is not an ADFS solution. ADFS is a SAML based technology which would require Access hosted environment to be configured and maintained for ADFS partners. ADFS and SAML integration are high-end/cost hosted authentication technologies which are only just becoming relevant to SMEs. ADFS integration is not currently something we offer, but we continue to monitor demand for technological solutions. Q: What would be the implications of hosting this SSO component on a server outside of the UK/EU? Users have full VPN connectivity to the remote server from all EU offices and we use a flat domain so all EU user accounts are accessible from the remote server. A: The application is a.net web application which needs to be installed on an IIS web server, and have LDAP line-of-sight for users wanting to SSO. As long as this holds, any server on the network could be used. 3

Q: Are any credentials stored and/or synced outside of network boundaries? We have very high security requirements and cannot allow user network credentials (passwords) to exist outside of the local network. A: No all that is passed is an encrypted ticket for that user s session. The on premise app is responsible simply for ensuring the user IS logged on to the network. Only the encrypted user name forms part of the ticket/conversation between on-premise app and hosted app. No passwords are accessed or passed. Q: Can users access the system when outside of the network (e.g. from home and not connected to VPN)? A: You can give your staff a manual user name and password to login if they go directly to the hosted app when not on the VPN (e.g. internet café). The user name and password you give them is a SelectHR application password, and is not reflective of their Windows credentials, although they can maintain similar user names/passwords. E.g. exclude domain\ from their Windows user name to generate a manual alternative in the application. Q: So if we do not generate application manual user names and passwords, does this mean you cannot access SelectHR when outside of the network? In other words, access with Windows credentials is only possible when connected to the network? A: Correct. Manual login credentials would be required when users are not authenticated with your network. Our Single Sign On experience can only be experienced when a user is authenticated i.e. on VPN or local network, as the user s browser needs line-of-sight access to the SSO app (installed on your internal network). It is an application to enable SSO when the local network user is already authenticated. 4

Architecture The user authentication is performed by a new web application using IIS Windows authentication to detect the browser user. This application is installed on the company intranet, accessible by users but not accessible by the hosted SelectHR application. When not authenticated, accessing any page in SelectHR will redirect the user to the single sign-on application, which can verify their Windows identity and redirect back to SelectHR. All communication is encrypted using a unique ticket stored in the user s session for the duration of the authentication process. When SelectHR receives an authenticated user name it can create a user session based on the mapping of Windows user names to system users. Optionally, the name can be displayed in the standard log in page and the user prompted for their password. This initiates a second redirect to the single sign-on application with the entered credentials and an Active Directory LDAP path to search. If the user credentials can be used to access the Active Directory then the user name is authenticated and redirected back to SelectHR to create a user session. Installation/configuration In order to enable single sign-on for hosted systems, a new web application must be installed on the company intranet that users will be accessing SelectHR from. TheSingle Sign On application should be installed in IIS with Windows Authentication enabled (anonymous access disabled). There is no other client side configuration for the Single Sign On application as all parameters are passed by SelectHR from the hosted database. The SelectHR Administrator and web application both have changes that require upgrading to the latest Version 1.7 builds. To enable single sign-on, open the Windows Administrator connected to the hosted system s database and navigate to the global configuration dialog. This is found from the home screen under Configuration - Configuration Options. Then by selecting the Global configuration. 5

On the global configuration dialog, the single sign-on section has 2 new elements at the bottom. Single Sign On URL entering a URL here enables the single sign-on app for hosted systems. If not using single sign-on or for local intranet systems this should be left blank and the traditional authentication methods will be available. If a single sign-on URL is entered, it should be in a format that can be accessed from the end user s web browser, not the hosted system. The hosted SelectHR application does not require access to this URL. Prompt for password when using single sign-on when checked this will require the user to confirm their Windows password before gaining access. If this is enabled, an Active Directory LDAP path (or paths) must be provided that can be used by the single sign-on app to authenticate the user s credentials on their own intranet. This uses the existing LDAP search path section that is used for local intranet single sign-on. This can be used in conjunction with the Disable Manual Sign-On option (under Manual Sign On Settings) to prevent the user from changing the detected Windows user name or to allow them to use an alternative manual user name and password. There is no danger of a user entering a different user s credentials as the single sign-on application matches the entered user name to the IIS authenticated user name. The Windows user name template is still used to generate default user names when users are created but these should be checked in the user manager as single sign-on access can only succeed if the authenticated Windows user name is mapped to an existing system user with a valid role and menu assigned. 6