AL-Infotech

What is the easy and simple way of activating Central User Administration (CUA)via SCUA? Customers that have implemented the Central User Administration in lower releases have had to read and skim through cookbooks and adhere to the different set-up procedures of the ALE landscape used to propagate the user data and input methods like UserClone in transaction WE20 (managing partner profiles), bearing in mind upper and lower cases for the different methods.

There is good news for you. The setup of CUA is now extremely simple and easy. All you have to do to activate the CUA, regardless of whether you want to set up a complete new CUA just add a new client to the CUA, is activate the CUA via transaction SCUA. So, no more fumbling in ALE configurations and partner profile management is needed!

The process, in short, is as follows:

1. Log on to the new child system and create a communication user for the CUA. Assign this user a customer copy of the following two roles: SAP_BC_USR_CUA_CLIENT, SAP_BC_USR_CUA_SETUP_CLIENT. The latter can be removed from the communication user after CUA activation.

2. Create the RFC connection(s) between central system and client.

3. Create a new logical system for the CUA client

4. Assign the logical system to a client

5. Go into transaction SCUA, enter the logical system and save. This will generate the ALE distribution model including partner profiles.

6. If you configure a CUA newly from scratch you have to customize the field distribution in transaction SCUM.

7. Migrate new users into your CUA central using transaction SCUG.

Let’s look at the details and do it. The CUA landscape we start with is as follows: We have a central system in client 100 on a Web Application Server stand-alone called TT1. We have two child systems in client 200 and 300. Now, we want to add client 400. So, how do we start? Create the communication user on client 400.

So, we log on to client 400 and create the communication user via transaction SU01.

This user has also been assigned the roles Z_SAP_BC_USR_CUA_CLIENT and Z_SAP_BC_USR_CUA_SETUP_CLIENT, which are custom copies of the pre-delivered SAP roles.

Now we have to create the RFC connection. To do this, we log onto the central system client 100 in system TT1 and go into transaction SM59.

We maintain the technical settings for the RFC connection.

And we maintain the communication user in this RFC connection.

What is the next step? To create a logical system for the new client 400. This is done in transaction SALE on the central system. Navigate to the menu path for logical systems and click on Define Logical System.

On the next screen enter a new value for TT1CLNT400 and save.

Then, go back with the green arrow and double-click on Assign Logical System to Client. On the next screen double-click on client 400.

Assign the logical system TT1CLNT400 to client 400.

Please note that the setup of the CUA landscape in our example spares us the burden of creating an RFC connection from the new daughter system client 400 back to the CUA central client 100, because we are in ONE system only, namely the TT1.

What is left to do? Well, all you have to do now is go into transaction SCUA, add the new child system TT1CLNT400 there, and click on save. Let us do it.

After you have saved your entries, you will see the following logs.

So, activities you formerly had to do yourself like creation and generation of the ALE partner model and input of methods in the ALE model are now done AUTOMATICALLY for you.

If you have not configured it yet, you can now maintain the field distribution in transaction SCUM. This transaction allows you to configure on a field level where you want to allow fields of the user master record to be maintained. Optionally you can just take the SAP defaults. So there is nothing to configure in transaction SCUM. The defaults will be distributed when you activate the CUA with transaction SCUA.

Then, you can migrate the users from child system 400 into the central system 100 using transaction SCUG.

For more information on CUA and how to implement it please take a look here: SAP Security Homepage” -> Security in Detail -> Identity Management -> Centralized Administration -> Cookbook: Central User Administration (Web AS ABAP 6.20 or higher release)

Hopefully, this weblog has shown how easy it has become to implement CUA. The crucial transaction SCUA has been powerfully enhanced, so that you are spared the burden of a lot of manual configuration. I hope you enjoy implementing CUA.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Landscape Strategies for SLD

“How many SLDs do I require?”

“Which applications rely on SLD data?”

“How can I synchronize my SLDs - today and in the future?”

“Where to run my SLD?”

Sound these questions familiar to you? Then, the SAP TechEd ‘06 session “Landscape Strategies for the System Landscape Directory of SAP NetWeaver” (ULM206) could be interesting for you!

Although system landscape directory of SAP NetWeaver (SLD) is defined as central provider of information about your system landscape, there are cases where you might require more than one SLD in your system landscape. Therefore, it is a good idea to think about a strategy how to introduce and run SLD in your system landscape.

After a short introduction to SLD itself, you will learn basic SLD concepts, options, relevant aspects, and examples how to integrate SLD in your landscape. Also, you will get an outlook to upcoming features that could influence your strategy as well.

As a result, you should get a foundation to analyze your requirements and decide how many SLDs you require, if/how to synchronize them and where to run them in your landscape.

My colleagues Matt Kangas (SAP TechEd ‘06 Las Vegas), Yu-Nong Zhang (SAP TechEd ‘06 Bangalore), and I (SAP TechEd ‘06 Amsterdam) are looking forward to welcome you in our session!

Single-Sign on in your SAP Landscape has changed with the gradual introduction of the SAP Web AS Java for use with each of your applications. With the delivery of SAP’s most widely used J2EE application, the SAP NetWeaver Portal; and the use of the Web AS Java for many other Java applications being delivered by SAP, there is an increasing need for the Java Engines within your enterprise to be enabled for Single-Sign On.

Overview

This article will use a real-life, 3 step example of Integrating Single-Sign On between two SAP Portals, to illustrate how to use SAP Logon Tickets for J2EE Application SSO. Using this single-sign on capability, your users will be able to move seamlessly between your different SAP Web AS Java systems, without having to re-enter their passwords.

• The Portals systems used in the example are both SAP NetWeaver Portal (NW04s) systems.
• Both Portals use the same ABAP Central User Administration (CUA) system as their authentication source (User accounts already exist in this CUA system, and basic authorization is in place)
• Both Portals User Management Engines (UME) are configured and allow logon using these user names, and generate SAP Logon tickets.

In this example, we are going to go through 3 basic steps in order to enable this SSO capability:

1. Key Exchange – As the basis for any of the SAP System Trust relationship, we will need to take the Public key from each of the SAP Systems and exchange them, to allow non-repudiation. This step allows each of the Portal system to be certain that the SAP Logon ticket it receives was really created by the System it has been told to trust.

2. User Store Adjustment – This is where you define which systems are to be trusted by the Enterprise Portal System. After Step 1, the Portal has the Pubic Key, but it still has not been told who to trust. Here we define a Trusted System with 3 parameters, so that it can match them to the proper key in the Keystore.

3. Adjust JAAS Login Module Stacks – After the trusted system has been defined, you still must adjust the login module stacks for two reasons:

• You want to adjust them to tell the J2EE Engine what order it should interpret different login mechanisms, and what is sufficient (i.e., look for login ticket, then password, then digital certificate etc)
• You want to identify very specifically which systems that the J2EE Engine will trust, from the list of systems defined in step 2.

The reason for the complexity of the steps #2 and #3 is that it allows you a level of granularity of control about who is able to log on to your SAP Web AS Java, without being challenged for a password. It may seem like a pain, but it’s a necessary one.

Step 1: Key Exchange

The first step in the Single Sign-On setup is the key exchange between the two Portals, enabling the Portals to ensure that the communication is coming from a trusted source.

Download

1. In order to exchange the keys, first we must grab them by logging into each of the Portal’s with the Administrator user.

2. You then navigate to the System Administration -> System Configuration -> Keystore Administration -> Content Tab



3. Once there, you select the “ticketKeyStore” and the “Certificate: testkey” Click on the:

“Download verify.der File” button, and name the file SIDverify.der (In our example: EP1verify.der). This is to distinguish the keys from each other when you have them saved on your file system and wish to upload them again.

4. Repeat this procedure for the other portal system, EP2, and save the downloaded EP2verify.der file in the same directory as the first DER file.

Upload

1. The next step in exchanging these keys is the upload of the corresponding keys into the other servers Keystore.

2. Navigate to the System Administration -> System Configuration -> Keystore Administration -> Import Trusted Certificate tab.



3. In the EP2 system, click on the “Browse” button and navigate to the Ep1verify.der file that you downloaded earlier. Give it an appropriate alias, like EP1 and click on Upload.

4. Once uploaded, log into the OTHER portal system as administrator, and repeat the steps, except this time uploading the Ep2verify.der file and using the Alias EP2.

That completes the Key exchange

Step 2: User Store Adjustment

Once you have exchanged the keys of the servers that are designated to trust each other, you will need to adjust their user stores, so that they are able to accept the SAP Logon tickets that are generated as cookies in the browser, by their counterpart portal upon the user initial login. This step defines which J2EE servers SAP Login tickets that the EvaluateLoginTicketModule will accept.

Open the Visual Admin Tool

1. Log into J2EE Visual Admin tool on EP1

2. Server node -> Services -> Security Provider

3. Runtime -> User Management tab

4. Click on Edit (pencil)

5. Click on “Manage User Stores” button(Bottom-right hand corner)

6. Select the “UME User Store” and corresponding “EvaluateLoginTicketModule“:



a. Click on “View/Change Properties”

b. Add in the three corresponding options for:

Trustedsys1 = EP2,000

Trustediss1 = CN=00,OU=EP2,OU=DE,O=mySAP.com Workplace,C=DE

Trusteddn1 = CN=00,OU=EP2,OU=DE,O=mySAP.com Workplace,C=DE

c. Once you have added the definition of the Portal J2EE System into the Login module, repeat the process on the other Portal System.

Click OK.

(Please Note that the parameters defined in this section need to correspond EXACTLY to the SID of the system, and the values laid out in the Keystore Administration under “DN of Owner” and “DN of issuer“. Copy and Paste the values from the actual Keystore iview, where possible, to avoid error.)

Step 3: Adjust JAAS Login Module Stacks

In order to instruct the J2EE Engine to accept SAP Logon Tickets generated by another J2EE Server, we need to be certain that our J2EE Server is set up to look for, interrogate and authenticate using other systems’ SAP Logon Tickets, before it challenges the user with a username and password.
The SAP JAAS (Java Authentication and Authorization Service) Login Modules define which J2EE Applications allow/check for which authentication options.

In our case, we will want the SAP Enterprise Portal to:

i) Look for an SAP Logon Ticket, and allow authentication based on that, should it be valid.

ii) Ask for a Username and Password.

iii) If that username and password are correct, generate an SAP Logon ticket so that subsequent SAP ABAP Systems (R/3 for example) can be accessed without being further prompted for a username/password.

Open the Visual Admin Tool

1) Log into J2EE Visual Admin tool on EP1

2) Server node -> Services -> Security Provider

3) Runtime -> Policy Configurations tab

4) Select the Ticket Component

5) You will see here the Login Module stack for the ticket authentication, and we will need to adjust the Evaluate Ticket login Module.

6) Change to Edit Mode (pencil)

7) Highlight the com.sap.security.core.server.jaas.EvaluateTicketLoginModule

Click on Modify.

9) Here you will see the module configured with the option ume.configuration.active = true

10) We will need to add in the three parameters maintained in Step #2, when we adjusted the UME User Store:

trustedsys1= EP2,000

trustediss1= CN=00,OU=EP2,OU=DE,O=mySAP.com Workplace,C=DE

trusteddn1= CN=00,OU=EP2,OU=DE,O=mySAP.com Workplace,C=DE

Summary

Once the J2EE Engines have each been restarted, and one of your users logs into one of the Portal systems, as long as they have the same user name in both systems, and you have followed the steps related above, they will not be prompted when they navigate from one Portal to another. (Please keep in mind that this SSO capability is dependent on the SAP Logon Ticket still existing, so you cannot log out of the Portal and expect this to still work.)

Enjoy!