<?xml version="1.0" encoding="utf-8"?>
<ManualTopic ID="/baanerp/tt/onlinemanual/single_sign_on" xml:lang="en">
	<Header>
		<Title xmlns:HTML="http://www.w3.org/TR/REC-html40">To set up Single Sign On</Title>
		<Keyword ContextSensitive="No"><Level1>SSO</Level1>
		</Keyword>
	</Header>
	<AimSection><Paragraph class="Default">The principle of an Single Sign On (SSO) solution is to remove authentication from the applicative code. The goal is to offer a globally secured software environment which allows users to provide his or her credentials once in order to access multiple applications. Since the introduction of MyDay it is possible to drill-back from Key Performance Indicators (KPI) into the details. A disadvantage was that if the end user executed a drill-back on ERP LN a request for a login code with password appeared. To avoid this extra login, ERP LN is now SSO enabled. In this way the user only has to login once to use MyDay and ERP LN.</Paragraph>
	</AimSection>
	<GeneralSection><SectionTitle>Infor Security Service</SectionTitle>
		<Paragraph class="Default">Infor implemented an Security Service based on Central Authentication Service (CAS). CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. This Security Service is adopted by ERP LN.</Paragraph>
		<Paragraph class="Default">SSO servers, also known as CAS servers, use HTTPS for secure communication. HTTPS only works when an SSL certificate has been installed in the web server where SSO runs. To let the communication process between HTTPS and SSO work fluently certificates are being used. Certificates are like a passport to identify the identity of an SSO server. In this way it is possible to check if the server is a valid and secure server to communicate with and to check if the correct server is behind the requested URL. Certificates are stored on the web server where SSO runs and transferred to the client when it connects.</Paragraph>
		<List><ListItemHead>Acquiring a certificate</ListItemHead>
			<ListItem>The server requires a certificate which has been generated by a trusted authority. ERP LN only accepts certificates which have been generated by this trusted authority or by the system administrator.</ListItem>
			<ListItemHead>Using a certificate</ListItemHead>
			<ListItem>Certificates are generated for a particular system and contain a hostname. Connecting to that system using a different hostname will result in a certificate which will be marked as un-trusted. Keep this also in mind when renaming a host. A new certificate has to be generated. Each server which requires a certificate needs its own certificate.</ListItem>
			<ListItemHead>Verification of certificate</ListItemHead>
			<ListItem>If an end user logs in using the WebTop, this user will be redirected to the CAS server. First response of CAS is to send the certificate to the client. This certificate needs to be verified by the client to make sure that the server is a valid server. For this purpose the client has a list of all valid certificates. The so-called root certificates. This list is updated automatically. The client logs in and receives its username.</ListItem>
			<ListItem>Next step is to send the username to the ERP LN server to actually login. The ERP LN server verifies the user with the CAS server to approve the login. The ERP LN server also needs to verify the certificate and needs an up to date list of the <GUIRef href="" role="manual">root</GUIRef> certificates</ListItem>
		</List>
		<Paragraph class="Default">To install and setup the Infor Security Service you need to refer to the <DocRef>Infor MyDay System Administration Guide</DocRef>. In case of questions or problems you can contact the Online Support Web site at <Link href="http://www.infor365.com" role="wwwlink">www.infor365.com</Link>.</Paragraph>
	</GeneralSection>
	<GeneralSection><GeneralSection><SectionTitle>Password aging</SectionTitle>
			<Paragraph class="Default">On a UNIX or Linux system, accounts with password aging that are trying to log in to ERP LN through SSO will not be blocked in case these accounts are about to expire, have expired, or are disabled. However, Windows systems will block these accounts.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Ticket granting cookie</SectionTitle>
			<Paragraph class="Default">The logon window of the Infor SSO service is used to enter username and password, from then only tickets are passed between applications, that need to be validated with the <Link href="/baanerp/tt/glossary/glossary#SSO" role="glossary">SSO</Link> service. Refer to the <Link href="/baanerp/tt/onlinemanual/single_sign_on_login" role="session">Single Sign On Login Process</Link> for more information.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>SSO for ERP LN</SectionTitle>
			<Paragraph class="Default">The <Link href="/baanerp/tt/glossary/glossary#SSO" role="glossary">SSO</Link> credentials will not be used to further logon into for example the RDBMS or another Application Server. For now the impact will be limited to the authentication service: <GUIRef href="" role="manual">Baan Login</GUIRef>. This is a rexec like service that currently accepts usernames and passwords as credentials to authenticate users. If a user is authenticated, Baan Login will start the Enterprise Server virtual machine (bshell).</Paragraph>
			<List><ListIntro>The Baan Login protocol had two options:</ListIntro>
				<ListItem>LOGIN_USER (for username / password validation and subsequent startup of a process)</ListItem>
				<ListItem>VALIDATE_ONLY (for username / password validation only).</ListItem>
			</List>
			<Paragraph class="Default">Next to these two options a new option is created:</Paragraph>
			<List><ListItem>SSO_LOGIN_USER for the correct BSE environment information to start the bshell.</ListItem>
			</List>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>Infor SSO User Identity in ERP LN</SectionTitle>
		<Paragraph class="Default">Generally there are two different kind of users:</Paragraph>
		<List><ListItem>Operating System User (OS User)</ListItem>
			<ListItem>Application User</ListItem>
		</List>
		<Paragraph class="Default">The <GUIRef href="" role="manual">Infor SSO user</GUIRef> will be a third kind of user which is needed for the Infor Security Service. The major role of the <GUIRef href="" role="manual">SSO User</GUIRef> besides authentication, is to make the mapping towards the correct OS User and Application User.</Paragraph>
		<Paragraph class="Default">For security reasons, an Operating System (OS) group, for example <GUIRef href="" role="manual">bsp</GUIRef> must be setup. This group can only contain OS users that are allowed to do administrative tasks.</Paragraph>
		<Paragraph class="Default">For an ERP LN environment on Windows, a <GUIRef href="" role="manual">Generic System User</GUIRef> must be created and be available on OS level, for example: <GUIRef href="" role="manual">infor_ln</GUIRef>. Default, this <GUIRef href="" role="manual">Generic System User</GUIRef> will be used when <Code>ipc_boot</Code> is started. For individual users this can be overruled by explicitly configuring another OS User. Both the OS User and the SSO user are configurable in the <GUIRef href="" role="manual">User Data (ttaad2500m000)</GUIRef> session and converted to runtime.</Paragraph>
		<Paragraph class="Default">It is possible to use Infor Security and the OS authentication for one user.</Paragraph>
		<ExampleSection><SectionTitle>
                                 Example
                              </SectionTitle>
			<Paragraph class="Default">For example in the following situations:</Paragraph>
			<List><ListItem>The administrator has enabled SSO for all accounts, and wants for his own account (as fallback) keep an option to logon with his OS account in case SSO does not work.</ListItem>
				<ListItem>Some client applications can not work (yet) with Infor SSO and other applications like for example MyDay do not operate without Infor SSO.</ListItem>
			</List>
		</ExampleSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>Configuration of SSO on ERP LN</SectionTitle>
		<Paragraph class="Default">The introduction of <Link href="/baanerp/tt/glossary/glossary#SSO" role="glossary">SSO</Link> required changes on the ERP LN side. A new session <Link href="/baanerp/tt/ams/ttams0100m000" role="session">SSO Parameters (ttams0100m000)</Link> is defined and the <Link href="/baanerp/tt/ams/ttams1100s000" role="session">User Data (ttams1100s000)</Link> session is extended with extra fields. Also the Convert to Runtime DD session required changes.</Paragraph>
		<Note><SectionTitle>
                                 Note
                              </SectionTitle>
			<Paragraph class="Default">To prevent malicious end-users trying to change the configuration in the User Data in such a way that they can start a Bshell as for example OS user root, the file <Code>sso_permissions.xml</Code> must be created manually. Place this file in the BSE of the logic service, for example in: <Code>c:\windows\baan\security</Code>. Infor Security integration will not work if <Code>sso_permissions.xml</Code> is not created.</Paragraph>
		</Note>
		<GeneralSection><SectionTitle>Session SSO Parameters (ttams0100m000)</SectionTitle>
			<Paragraph class="Default">First start the session <Link href="/baanerp/tt/ams/ttams0100m000" role="session">SSO Parameters (ttams0100m000)</Link>. Fill in the URL towards the Infor SSO Service you have setup earlier, you must also supply the <GUIRef href="" role="manual">Generic System User</GUIRef> in this session. Click <GUIRef href="" role="manual">Dump</GUIRef> to placed the information in the <Code>$BSE/lib/sso_config</Code>.</Paragraph>
			<Paragraph class="Default">Refer to the online help of this session for more specific field information.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Session User Data (ttams1100s000)</SectionTitle>
			<Paragraph class="Default">In case SSO is activated through <Link href="/baanerp/tt/ams/ttams0100m000" role="session">SSO Parameters (ttams0100m000)</Link> the <Link href="/baanerp/tt/ams/ttams1100s000" role="session">User Data (ttams1100s000)</Link> session will be extended with the following two fields:</Paragraph>
			<List><ListItem>Infor SSO User.</ListItem>
				<ListItem>Use Generic System User.</ListItem>
			</List>
			<Paragraph class="Default">The <GUIRef href="" role="manual">Infor SSO User</GUIRef> must be known at the <GUIRef href="" role="manual">Infor Security Service Server</GUIRef> and the <GUIRef href="" role="manual">Generic System User</GUIRef> must be created on OS level and in the <Link href="/baanerp/tt/aad/ttaad2500m000" role="session">User Data (ttaad2500m000)</Link> session of ERP LN.</Paragraph>
			<Note><SectionTitle>
                                    Note
                                 </SectionTitle>
				<Paragraph class="Default">In case of a Windows install. The <GUIRef href="" role="manual">User Data (tams1100m000)</GUIRef> session will contain another extra field, namely the <GUIRef href="" role="manual">Generic System User Password</GUIRef> field. On Windows the plain password to switch to a certain user is mandatory. This password will be immediately encrypted and during the conversion to runtime placed into the <Code>$BSE/lib/sso_config</Code> file as <Code>gu_passwd</Code>.</Paragraph>
			</Note>
		</GeneralSection>
		<GeneralSection><SectionTitle>Conversion to runtime</SectionTitle>
			<Paragraph class="Default">After you have entered the needed <Link href="/baanerp/tt/glossary/glossary#SSO" role="glossary">SSO</Link> information you must activate <GUIRef href="" role="manual">SSO</GUIRef> for the ERP LN users as follows:</Paragraph>
			<ProcedureList><ListItem>Save and Close the <GUIRef href="" role="manual">User Data (ttams1100s000)</GUIRef> session. You will return to the Main <GUIRef href="" role="manual">User Data (ttaad2500m000)</GUIRef> session.</ListItem>
				<ListItem>On the <GUIRef href="" role="menu">Specific</GUIRef> menu in the <GUIRef href="/baanerp/tt/aad/ttaad2500m000" role="session">User Data (ttaad2500m000)</GUIRef> session, click <GUIRef href="/baanerp/tt/aad/ttaad2500m000#exec.user.0" role="command">Convert Changes To Runtime DD</GUIRef>. The <Link href="/baanerp/tt/ams/ttams2200m000" role="session">Convert Changes to Runtime DD (ttams2200m000)</Link> session appears.</ListItem>
				<ListItem>Enter the required data in the <GUIRef href="/baanerp/tt/ams/ttams2200m000" role="session">Convert Changes to Runtime DD (ttams2200m000)</GUIRef> session. Refer to the session help for details.</ListItem>
				<ListItem>Click <GUIRef href="/baanerp/tt/ams/ttams2200m000#exec.cont.process" role="command">Convert</GUIRef> to convert the user data to the <Code>$BSE/lib/user</Code> folder on your system. The following filles will be created: <List><ListItem>sso_user:&lt;SSO User&gt;</ListItem>
						<ListItem>baanuser:&lt;baanuser&gt;</ListItem>
					</List>
				</ListItem>
			</ProcedureList>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>Performance</SectionTitle>
		<Paragraph class="Default">The logon process will take multiple validation steps. As the Infor SSO service will be on a central server, several of these steps will include network round-trips. This new approach will therefore slightly increase CPU consumption on the WebTop server and also slightly increase the network load. The central Infor SSO server must be powerful enough to handle multiple parallel authentication requests. From a user perspective however, an extra logon step is removed. The end-to-end process for the end user therefore will be faster.</Paragraph>
	</GeneralSection>
	<RelatedTopics><SectionTitle>
                              Related topics
                           </SectionTitle>
		<RelTopic></RelTopic>
	</RelatedTopics>
</ManualTopic>
