Single Sign-On for Runtime Workbench

[] [] [] [] [] [] [] [] []

Related:

  1. Securing Payloads in Message-MonitoringSymptom You want to restrict access to message payloads in...
  2. Securing Payloads in Message-MonitoringSymptom You want to restrict access to message payloads in...
  3. ES: No authorization for creating workbench requestSymptom In the Template Modeller of Enterprise Search a workbench...
  4. Release Strategy:OEWB:ACS Order Engineering WorkbenchSymptom You are planning to install or upgrade the add-on...
  5. Use of network security productsSymptom Inquiries: Preconditions when using network security productsSecure authentication and...
  6. SPNego WizardSymptom You are configuring Kerberos Authentication mechanism on SAP AS...

Symptom

Repeated logon in the Runtime Workbench.
Other terms

Single Sign-On, message monitoring, end-to-end monitoring

Solution

The Runtime Workbench is set up to use Single Sign-On with logon tickets. That is, once you have successfully logged on to the Runtime Workbench, a user ticket is saved as cookie in the browser. When you navigate to screens on other systems, for example, during the detailed display in the message monitoring or in the end-to-end monitoring, the ticket can be used to authenticate the user. For this purpose, the other systems must accept the J2EE engine that hosts the Runtime Workbench as the system which issues the ticket. The relevant procedure is described in the attached document (Configuring the SAP Web AS ABAP to Accept Logon Tickets from the J2EE Engine, P 17) or in the sections of the on-line help specified there.
However, you must bear in mind the following:
Problems occur if the Runtime Workbench J2EE Engine System ID is the same as the system ID of any connected system (such as the Integrated Server), since the J2EE always logs on as client 000, which always exists in the ABAP stack. To avoid this, you must change the default client of the J2EE Engine. Proceed as follows:In the J2EE Visual Administrator, open the Node Server->Services->Configuration Adapter, then select the cluster_data->server->cfg->services node, and switch to editing mode.Go to the com.sap.security.core.ume.services property sheet, and set the value of login.ticket_client to a client that does not exist in the ABAP stack.Restart the J2EE Engine.Now create a new “SAPLogonTicketKeypair” in the J2EE Visual Administrator (the old entries with this name must first be deleted) with a distinguished name that is different from that of the ABAP stack (the common name of the key pair must correspond to the system ID, however). Ensure that you select the DSA algorithm and a key length of 1024.Call Transaction STRUSTSS02, and import the certificate you have created to the ABAP stack (see also the attached document). You must add the client selected above (the login.ticket_client parameter) to the SSO access control list (ACL) entry.In addition, you must ensure that all systems that are included in the navigation are located in the same DNS domain and that the domain is specified in the URLs. To do so, proceed as follows:Adjust the icm/server_port_ (HOST-section) and icm/host_name_full profile parameters correspondingly.Enter the long host name for the Runtime Workbench and the central Monitoring Server in the exchange profile (the com.sap.aii.connect.rwb.name, and com.sap.aii.rwb.server.centralmonitorying.r3.ashost properties) – that is, enter “abc.sap.com”, instead of “abc”, for example.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Leave a Comment