Using Logon Tickets for Single Sign-On for a reputed Client Project
In the existing scenario, an IBM websphere portal running on a Web Application Server integrates a Web Dynpro Java application running on a Web AS Java. The Web Dynpro application reads data from an ABAP system using adaptive remote function call (adaptive RFC). The User Management Engines (UME) of the Web AS Java is configured to authenticate users against an ABAP-based SAP system. The ABAP system from which the Web Dynpro application retrieves data and the ABAP system from which the UMEs read user data are not the same system. However, users have the same user IDs in both systems. For achieving SSO, SAP Logon tickets will be used in this scenario.
The user authenticates him or herself using any of the supported authentication mechanisms. After successful authentication, the system issues/accepts the logon ticket, which he or she can use for access to successive systems.
The characteristics of a logon ticket include:
1) The logon ticket is stored as a non-persistent cookie in the user’s Web browser with the name MYSAPSSO2. It is deleted when the user logs off or closes his or her Web browser.
2) The maximum life span of the logon ticket is specified in the ticket-issuing system parameters.
3) It contains the user ID, but not the user’s password. Instead it is digitally signed by the ticket-issuing server. This is digital signature is verified by accepting systems to allow user access
1) For the new project, the existing IBM portal system is the ticket-issuing system.
2) Users log on to the portal using any supported authentication method, such as client certificates or Windows authentication.
3) Once they are successfully authenticated, they are issued with a logon ticket. This logon ticket is used to authenticate them in all other components of the system landscape.
1) Users have the same user ID in all of the systems they access using the logon ticket. Passwords do not have to be the same in all systems.
2) The user has an account in the active user store on the SAP J2EE Engine.
3) The end users Web browsers accept cookies. In Internet Explorer 5.0, accept session cookies for the local intranet zone.
4) Any Web servers or SAP Web AS servers (to include the SAP J2EE Engine) that are to accept the logon ticket as the authentication mechanism are located in the same DNS domain as the issuing server. The logon ticket cannot be used for authentication to servers outside of this domain.
5) The clocks for the accepting systems are synchronized with the ticket-issuing system.
If you do not synchronize the clocks, then the accepting system may receive a logon ticket that is not yet valid, which causes an error.
6) The issuing server must possess a public and private key pair and public-key certificate so that it can digitally sign the logon ticket.
7) Systems that accept logon tickets must have access to the issuing server’s public-key certificate so that they can verify the digital signature provided with the ticket.
8) The UMEs of the Portal and Web Dynpro systems are set up to authenticate users against the ABAP system.
The following description helps you find out which method of Single Sign-On to use in a given scenario.
Configuring the Use of Logon Tickets:
For existing scenario, the following tasks will be performed:
1) Setting the existing portal to issue Logon Tickets on successful authentication.
2) Setting up the Web Dynpro Application for Logon Tickets.
3) Configuring the SAP WAS Engine to accept logon tickets from other servers.
4) Configuring the ABAP System to accept Logon Tickets from the J2EE Engine
1) Web Dynpro System Accepts Tickets From ISP Portal.
2) Single Sign-On Between the Portal and the ABAP System.
3) Use of logon tickets on the server.
A) Setting up the ISP Portal to issue Logon Tickets:
B) Setting up the Web Dynpro Application for Logon Tickets:
1) Configure the web Dynpro application to require authentication.
The configuration property Authentication has to be assigned the value TRUE.
2) Configuring the Web Dynpro application that receives data from a SAP system with an adaptive RFC model so that it logs onto the SAP system with the user’s logon ticket.
3) While using adaptive RFC model in a Web Dynpro application, two JCo destinations are automatically created in the Web Dynpro Content Administrator.
A) When defining the JCo destination for application data(User Specfic), select authentication method Ticket.
The users logon ticket is sent to the SAP system.
B) When defining the JCo destination for metadata , only authentication method User/Password is supported.
C) SAP WAS Configuration:
1) Importing the public-key certificate (or the issuing CA’s root certificate) of the portal system into the SAP WAS keystore view that the Web Dynpro system uses for verifying logon tickets
a) Export the ISP Portal server’s public-key certificate.
b) Import this certificate into the TicketKeystore view on the SAP WAS Engine.
Key Storage -> TicketKeystore -> Load