PROBLEM

If two Secure Login Server instances are running independently, i.e. not in a NetWeaver cluster, their configuration is not synchronized. While Secure Login Server Administrator Console allows to maintain the same X.509 PKI by exporting and importing Certificate Authority objects, it is not possible to create exactly the same Client Authentication Profiles and Policy Groups, as they get a random GUID as part of their URLs, even if the same display names are chosen. This leads to compatibility issues if such independent SLS instances shall be used for load balancing or fail-over.

SOLUTION FOR SECURE LOGIN SERVER 2.0 SP06


With SSO 2.0 SP06, Secure Login Server allows to edit the GUID part of client profile URLs. Just enter the same name in “Profile ID” for equivalent profiles on each SLS instance to get the same URL path.


All other migration operations – PKI, profile configurations, login stack and module configuration – can be done inside Secure Login Server Administration Console, and without restarting the server.


Continue with chapter FINALIZING TARGET SYSTEM.



MANUAL SOLUTION FOR 2.0 SP05 OR OLDER

A manual export and import of all configuration items except the PKI objects can be done with AS Java Config-Tool, as illustrated in this blog.

PREREQUISITES

  1. AS Java Source System is up and running, Secure Login Server configuration is complete and tested.
  2. AS Java Target System is up and running, no Secure Login Server deployed yet, or Secure Login Server deployed but not configured yet.
  3. On both systems, you are able to launch AS Java Config-Tool, which may require a remote desktop or X session:
    • LINUX:        cd /usr/sap/SID/INST/j2ee/configtool ; ./configtool.sh
    • WINDOWS: cd D:\usr\sap\SID\INST\j2ee\configtool && configtool.bat
  4. There is a file share available in both systems that allows to write and read from both systems, because AS Java Config-Tool uses files on the remote system only.
  5. On both systems, SAP JVM is running with the same Java JCE Security Policy; recommended is JCE Unlimited Strength Jurisdiction Policy Files if applicable for your country: Download the Java 1.6 policy files and extract them here (rename the original files):
    • LINUX:        /usr/sap/SID/SYS/exe/jvm/OS/sapjvm_6.xxx/sapjvm_6/jre/lib/security/
    • WINDOWS: D:\usr\sap\SID\SYS\exe\jvm\OS\sapjvm_6.xxx\sapjvm_6\jre\lib\security\
  6. The Secure Store Key Phrase must be the same on both systems; change it with AS Java Config-Tool if this is not the case.

    Note: Changing the JCE Security Policy requires to shut down AS Java, and to restart AS Java Config-Tool before changing the Key Phrase; changing the Secure Store Key Phrase is effective only if “Apply Changes” is performed. Do not start AS Java before all these steps are successfully done in this order. The target system can be kept stopped until the export/import procedure is completed.

EXPORT FROM SOURCE SYSTEM

  1. Launch AS Java Config-Tool
  2. Switch to configuration editor mode
  3. Switch between view and edit mode
  4. Select node “SecureLoginServer”
  5. Select menu item “Export”
  6. Give a valid file name in the file share, press “Start export”. Occurring errors may be caused by missing write permissions in the file share.
  7. If exporting is successful, press “Close window”
  8. Close AS Java Config-Tool with its “Exit” menu

IMPORT INTO TARGET SYSTEM

  1. Launch AS Java Config-Tool
  2. Switch to configuration editor mode
  3. Switch between view and edit mode
  4. Select root node “Configurations”
  5. Select menu item “Create sub-node”
  6. Enter name “SecureLoginServer”
  7. Press “Create”, then “Close window”
  8. Select the new node “SecureLoginServer”
  9. Select menu item “Import”
  10. Select the exported configuration from the file share
  11. Press “Start import”
  12. Press “Close window”
  13. Close AS Java Config-Tool with its “Exit” menu

FINALIZING TARGET SYSTEM


ALTERNATIVE 1 – SINGLE ITEM PKI EXPORT AND IMPORT

  1. Once the configuration import was successfully done, AS Java can be started (or must be restarted, if already up and running).
  2. Now Secure Login Server can be deployed according to the product guide.
  3. Don´t forget to associate the SLAC_SUPERUSER role to your NetWeaver administrator.
  4. Open NetWeaver Administrator > Configuration > Authentication and Single Sign-On.
  5. Create all Policy Configurations and Login Modules as in the source system.
  6. Now Secure Login Administrator Console can be opened.
  7. In Certificate Management, create your target system PKI by importing the PKI objects from your source system (e.g. by having both SLAC browser windows open and using your Desktop as import/export share).
  8. Edit all profiles in Client Management > Client Authentication Profiles, open User Authentication, and select the correct “Policy Configuration” values.
  9. Edit all profiles in Client Management > Client Authentication Profiles, open User Certificate Configuration, and select the correct “User CA” values.
  10. Edit all profiles in Client Management > Client Authentication Profiles, open Secure Login Client Settings, and select the correct “Host Name” and “Port” values.
  11. Edit all profile groups in Client Management > Profile Groups > General, and select the correct “Host Name” and “Port” values.
  12. In Client Management, enable all profiles that are eventually locked.


ALTERNATIVE 2 – BULK PKI EXPORT AND IMPORT


If you have created a large number of Secure Login Server PKI objects, e.g. because you have issued server keys and certificates manually, the manual steps of single item export and import are quite time consuming.

Alternatively, the complete Secure Login Server certificate view can be cloned.

  1. Once the configuration import was successfully done, AS Java can be started (or must be restarted, if already up and running).
  2. Now Secure Login Server can be deployed according to the product guide.
  3. Don´t forget to associate the SLAC_SUPERUSER role to your NetWeaver administrator.
  4. Open NetWeaver Administrator > Configuration > Authentication and Single Sign-On.
  5. Create all Policy Configurations and Login Modules as in the source system.
  6. In the source system, open NWA > Certificates and Keys, search for “SecureLoginServer”.
  7. Press button “Export Entries To File” in the Key Storage Views menu.
  8. Select File Type “SAP KeyStore (.view)”.
    Note: This file format is not encrypted or password protected, all private keys are contained in plain. But the format is required because it preserves all entries´ names without converting them to lower case. The export operation will download this file to your local client. Be careful and make sure it does not leave your local environment. If possible, save this file to an encrypted partition or (encrypted) USB memory stick.
  9. Press “Download” to save a file named “SecureLoginServer.view”.
  10. In the target system, open NWA > Certificates and Keys.
  11. Search for “SecureLoginServer” – it should not exist yet.
  12. Press button “Add View” in the Key Storage Views menu.
  13. In the dialog “New Key Storage View”, enter “SecureLoginServer” as “View Name”, and some text in “Description”.
  14. Press button “Create”.
  15. Select the created view named “SecureLoginServer”.
  16. Press button “Import Entries From File” in the Key Storage Views menu.
  17. Select File Type “SAP KeyStore (.view)”.
  18. Choose your local Keystore View File named “SecureLoginServer.view”.
  19. Press “Import” to upload the file into the Key Storage View.
  20. Review the view named “SecureLoginServer” to make sure all private keys and certificates have been successfully imported.
  21. Delete the local file named “SecureLoginServer.view”. Use a secure wipe tool for this purpose, or perform a full formatting in case of an (unencrypted) USB memory stick.
  22. For Secure Login Server 2.0 SP06 PL02 or older, you have to grant security permissions now:
    1. Open the view´s “Security” menu.
    2. In “Domain Name”, search for “securelogin”.
    3. Select “Domain Name” entry “sap.com/SecureLoginServer”.
    4. Press “Modify”.
    5. Press “Grant New Permission”.
    6. In the dialog “Granting New Keystore Permissions”, select “All Actions”.
    7. Press “OK”.
    8. Press “Save”.
    9. Do the same for “Domain Name” entry “sap.com/securelogin.ui”.
  23. Now Secure Login Administrator Console can be opened.
  24. In Certificate Management, map all CA entries by pressing the button “Edit Type” and selecting the desired “Certificate Type”.
  25. Edit all profiles in Client Management > Client Authentication Profiles, open User Authentication, and select the correct “Policy Configuration” values.
  26. Edit all profiles in Client Management > Client Authentication Profiles, open User Certificate Configuration, and select the correct “User CA” values.
  27. Edit all profiles in Client Management > Client Authentication Profiles, open Secure Login Client Settings, and select the correct “Host Name” and “Port” values.
  28. Edit all profile groups in Client Management > Profile Groups > General, and select the correct “Host Name” and “Port” values.
  29. In Client Management, enable all profiles that are eventually locked.

CONCLUSION

That´s it. Now your target system´s Secure Login Server will look like the source system, except its hostname.

Be aware that any changes in one of the systems are still not synchronized after this procedure. Adding a client profile in one system requires a similar export/import with AS Java Config-Tool.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Carsten Olt

    Hi Stephan, that is a nice solution, thanks for that. I personally see this as a “workaround” only. Too complicated, to much manual steps to do, if a new client profile is created, same procedure… Why not just allow to modify the GUID values manually in the SLAC in future versions of SLS? Do you see a security issue by allowing this? Regards, Carsten

    (0) 
    1. Stephan Andre Post author

      Let me ask the other way round:

      Do you have practical experience from your projects that customers decide against a cluster with common database? If so, why?

      Having multiple stand-alone SLS´ synchronized is not just maintaining the URLs. There are more moving parts. If an URL (GUID) editor would solve most problems, we could think about it.

      — Stephan

      (0) 
      1. Carsten Olt

        Some arguments and views can be found here: http://scn.sap.com/thread/3563780

        In addition our experience is most the time, customers don’t setup clusters, don’t ask me why, maybe to complex, expensive, additional infrastructure & components required… Having just “failover” seems to be sufficient for most of our customers, HA/LB often is not required for them.

        (0) 

Leave a Reply