| SSO Service based on Central Authentication Service |  |
| Infor implemented an SSO 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 Service is adopted by ERP LN. SSO Service 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. Acquiring a certificate 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. Using a certificate 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. Verification of certificate If an end user logs in using the Web UI, 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 a ticket. Next step is to send the ticket to the ERP LN server to actually login. The ERP LN server verifies the ticket with the CAS server to approve the login and receives the user identity (name). The ERP LN server also needs to verify the certificate and needs an up to date list of the root certificates To install and setup the SSO Service you need to refer to the Infor PM Dashboards Administration Guide. In case of questions or problems you can contact the Online Support Web site at www.infor365.com. Password aging 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. Ticket granting cookie The logon window of the SSO service is used to enter username and password, from then only tickets are passed between applications, that need to be validated with the SSO service. Refer to the Single Sign On Login Process for more information. SSO for ERP LN The SSO 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: BaanLogin. This is a rexec like service that currently accepts usernames and passwords as credentials to authenticate users. If a user is authenticated, BaanLogin will start the Enterprise Server virtual machine (bshell). The BaanLogin protocol had two options: LOGIN_USER (for username / password validation and subsequent startup of a process) VALIDATE_ONLY (for username / password validation only). Next to these two options a new option is created: SSO_LOGIN_USER for the correct BSE environment information to start the bshell. Performance The logon process will take multiple validation steps. As the 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 Web UI 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. |