Expanding Single Sign-on for SAP Landscapes on i5/OS...Expanding Single Sign-on for SAP Landscapes on i5/OS Page 4 of 26 Environment To illustrate SSO, I implemented a simple environment

Expanding Single Sign-on for SAP Landscapes on i5/OS

This document can be found on the web, www.ibm.com/support/techdocs

Version Date: 10/23/2007

IBM Systems & Technology Group

Kolby Hoelzle [email protected]

© Copyright 2007, IBM Corporation Version 10/23/2007 http://www.ibm.com/support/techdocs Expanding Single Sign-on for SAP Landscapes on i5/OS Page 2 of 26

Preface Reducing and keeping administrative costs down is a challenge for most if not all organizations. One common source of high administrative costs is user and password administration. Forgotten passwords and locked user IDs not only result in lost productivity, but also a high volume of calls to the help desk. One strategy for reducing user ID and password administrative costs is single sign-on (SSO). By reducing the number of passwords a user must remember without sacrificing security, is one way that SSO can reduce administrative costs. This paper explores the possibility of expanding SSO from an SAP NetWeaver WebAS Java environment, running on the IBM i5/OS operating system, to include other elements of the enterprise including a Microsoft Windows network and other i5/OS systems.

About the Author Kolby Hoelzle is a member of the SAP on i5/OS development team, which is part of the i5/OS development lab in Rochester, Minnesota. He joined IBM in 1999 and has over six years of experience with SAP on the i5/OS platform, including two years working at SAP development in Walldorf, Germany as a member of the joint IBM SAP i5/OS porting team.

Acknowledgements Thank you to the following reviewers: Pat Botz, IBM STG Lab Services – Security Mike Frost, IBM STG Lab Services – SAP Bernhard Wolf, SAP – i5/OS Porting Team


Introduction This paper explores one possibility for expanding single sign-on (SSO) from an SAP NetWeaver® landscape running on the IBM® i5/OS® operating system to encompass your entire enterprise. SSO tends to be somewhat modular in nature and sometimes connecting the pieces to create a cohesive SSO environment proves to be elusive. Like most things in information technology (IT), there are many ways to accomplish the same thing. SSO is no different and many tactics and technologies have been developed to accomplish SSO. This paper provides an overview and discussion of one approach for expanding SSO from an SAP® landscape on i5/OS to include the entire enterprise. The purpose of this paper is to provide a proof of concept and a starting reference point for anyone interested in expanding SSO from an SAP landscape on i5/OS to the entire enterprise. In today’s heterogeneous IT environments, the way new technology is planned and implemented will depend on the environment itself.

Goals and Expectations of Single Sign-on When you hear the term “single sign-on” or “SSO”, you might first think of eliminating password prompts for end users. Though eliminating prompts might be popular with the end user, SSO should not be implemented for this reason alone. SSO should be viewed and implemented as a means of reducing the cost of user administration. The end goal should not be SSO, but rather reducing administration costs. SSO is one strategy that can be used to accomplish this goal. SSO is a user administration strategy that might include the central management of all of an enterprise’s users and their passwords or eliminating certain passwords altogether. SSO might provide authentication mechanisms that allow a user to authenticate once and obtain the necessary credentials that allow automatic authentication to subsequent systems and applications throughout the enterprise. An SSO solution might even provide a service to map one user ID to another so that a user does not have to manage different user IDs and passwords across multiple systems. Regardless of how SSO is implemented the main purpose of SSO should be to meet the goal of reducing costs. Administrative costs are reduced through SSO by simplifying the management of users and passwords for both the administrators and the users themselves. Password related problems tend to be a high percentage of the calls to the help desk in many organizations. Decreasing the number of passwords a user must remember has the potential to save help desk and administrative costs, not to mention lost productivity due to password related problems. Besides being one means for reducing costs, SSO can also help improve security. A user might be tempted to compromise security by writing down or caching the passwords if he or she has multiple user IDs and passwords to keep track of. The temptation might be even greater if your organization has implemented a security policy that forces users to change their password regularly. Decreasing the number of passwords that a user must keep track of lowers the tendency for a user to write down passwords and leave them easily accessible.


Environment To illustrate SSO, I implemented a simple environment. My environment consists of three basic components: an SAP NetWeaver landscape, i5/OS systems not running SAP applications, and a Microsoft® Windows® network and workstations. My simplified SAP landscape is a NetWeaver04s WebAS JavaTM application server running SAP NetWeaver Portal 7.0. The i5/OS systems are separate from the SAP systems and represent legacy applications running on i5/OS. All i5/OS systems, including the ones running SAP applications, are running V5R4. And finally, Windows workstations are used as the primary access point to the network resources. The Windows workstations are all part of a Windows domain. The Windows systems are a combination of Windows Server® 2003 and Windows XP. Figure 1 shows a representation of my simple enterprise environment.

Figure 1 Simple enterprise environment with multiple points of access In this environment, our user John arrives at work in the morning and the first thing that he does is sign-on to his Windows workstation using his Windows ID and password. After checking his e-mail, John decides to check the status of some i5/OS batch jobs that ran overnight. John starts iSeries® Navigator and selects the system he needs to access. Since his Windows ID doesn’t match his i5/OS user profile, John is prompted for his user profile and password. After checking the status of his batch job, John decides to do some work using SAP. John opens his web browser and navigates to his SAP portal. Again John is prompted to enter a user ID and a password. John remembers that his SAP user ID is the same as his Windows ID, but yesterday he was forced to change his SAP password so now it doesn’t match his Windows password. John thought that he remembered his new password, but after three attempts he was locked out and had to call the help desk. Not only is this additional cost to the help desk, but it also cost John in lost productivity. In our simple scenario, John has multiple different user IDs and passwords that he must keep track of. Combine this with security policies requiring passwords be

Windows Domain Controller

Other i5/OS applications

SAP Enterprise Portal on i5

SAP backend systems

John Smith's user IDs: u:jsmith p:myonepwd u:jsmith p:mypassword u:johns p:password u:smithj p:thepassword etc..


changed on a regular basis and it is easy to see how this could lead to problems keeping track of passwords, even in this simple environment.

Technology To make sense of my SSO implementation it is important to have an understanding of the concepts and technologies used to implement SSO in the environment I used as a reference for this paper.

Authentication vs. Authorization First off, it is important to differentiate between authentication and authorization. Simply put, authentication is the process of proving you are who you say you are and authorization is providing the rights to access specific system resources after you have authenticated. The user authenticates with a system on the network by providing the proper credentials, usually a valid user ID and password. Authorization, on the other hand, is usually transparent to the user and is usually only noticed when access to a specific resource is denied. Traditionally authentication and authorization processes use the same user registry. Each system and sometimes applications will have their own user registries for authentication and authorization. With SSO, authentication and authorization are often separated so that there is a separate user repositories for authentication and one for authorization. In certain situations, the user repository for authentication may not even be located on the system that is being accessed. In contrast to authentication, the user repository used for authorization will always remain with the system or application. This is necessary due to differences in authorities and how they are managed from one system or application to the next. Plus this provides additional flexibility since a user may have different levels of authority from one system or application to another. Since a user’s authority is managed by system or application and authorities are rarely changed after being established this has little impact on maintenance costs.

Kerberos The primary authentication mechanism used for my SSO implementation is based off of a protocol named Kerberos. Kerberos is a distributed authentication protocol that was developed by MIT researchers. Kerberos consists of three distinct parts: authentication server, ticket granting server, and services. The authentication server and ticket granting server, though logically distinct, often exist on the same physical machine and are collectively referred to as the key distribution center (KDC). At a high level, the authentication server verifies a user’s (principal in Kerberos terminology) credentials and grants what is called the ticket granting ticket or initial ticket. The ticket granting ticket is then used by the ticket granting server to grant a ticket for the specific service that the user is trying to access. The service can be a system or application on the network. Each service must be Kerberos enabled and configured to trust the KDC granting the tickets. All tickets are temporary and will


expire after a limited period of time, usually eight to ten hours. This forces the user to re-authenticate and limits the opportunity for someone other than the original user to intercept and reuse the ticket. To illustrate how Kerberos works, let’s take another look at our user John. When John arrives at work in the morning, he signs on to his workstation. John authenticates by entering his user ID and password. John is issued a ticket granting ticket by the KDC that is good for the rest of the day. Now John decides to access a network service (application) on a different machine. Since the KDC that issued John’s ticket granting ticket is trusted by that service, John is issued a ticket for access to that particular service. This ticket is also good for the rest of the day. John can immediately access this service without entering his credentials, since he has already been authenticated. For more information on Kerberos see http://web.mit.edu/kerberos Kerberos has been implemented and integrated in both Windows and i5/OS. SAP has implemented a Kerberos based authentication mechanism named SPNego for WebAS Java. SPNego enables Kerberos authentication and allows a user to authenticate using Kerberos tickets.

Microsoft Windows Active Directory Microsoft Windows Active Directory® is an integrated part of Windows Server technology and is a key component of the Windows Server domain controller. A domain controller is required for any Windows based network. Active Directory is used as the user repository for both authorization and authentication in a Windows based network. Active Directory is a critical part of a Windows network making it an essential part of my SSO solution. For more information on Microsoft Active Directory see http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx

Network Authentication Service Network Authentication Service (NAS) is the IBM implementation of Kerberos and the Generic Security Service (GSS) API. NAS is an integrated part of i5/OS, but it must be configured. NAS allows i5/OS users the ability to use Kerberos to access the i5/OS green screen or Kerberos-enabled client server applications running on i5/OS, such as iSeries Navigator. For more information on NAS, see http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzakh/rzakh000.htm?resultof=%22%

Enterprise Identity Mapping Normally used in tandem with NAS, Enterprise Identity Mapping (EIM) provides the capability to map one user ID to another. One person may have a different user ID for


different systems or applications even in the same organization. Tracking which user ID goes with which system or application can be as daunting as trying to remember all of your passwords, not to mention which password goes with which user ID. EIM allows a user to authenticate with one user ID and then use those credentials to map that user ID to another user ID. For more information on EIM, see http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzalv/rzalvmst.htm?resultof=%22%45%

Implementation Before discussing my implementation, I need to highlight three key assumptions that I based my implementation on. The first assumption is that a typical user’s primary point of access to network resources is a single workstation of some type. With Windows’ dominance of the desktop, I’m assuming that a Windows network and workstations are typical for many organizations. The second assumption is that the SAP Enterprise Portal system is the main access point to the SAP landscape and that SSO, using SAP technology, has been implemented between Enterprise Portals and the backend SAP applications. Since Enterprise Portals is a relatively new product offered by SAP, this assumption is probably less typical in current SAP landscapes. But as more and more customers take advantage of the benefits of portals, this may become more of the norm in the future. The third and final assumption is that all of the applications in the landscape can be enabled or configured to authenticate via Kerberos. In reality this is not the case. Although many applications have been enabled for Kerberos, there are many that have not. Enabling an application for Kerberos is something that usually must be done at the application development level. Besides Kerberos, other mechanisms do exist for implementing SSO. It is even possible that multiple mechanisms will be used in the same SSO solution. SSO solutions tend to be somewhat modular, the individual components of a solution might be implemented and provide value before the entire solution is in place. Not only does this provide a natural way to break up a big SSO project, but could also provide a way to manage the costs of the project itself. The implementation of my test environment consisted of the following components: creating a Microsoft domain which includes the KDC; configuring the i5/OS network authentication server and enterprise identity mapping; configuring the SAP user store to use Microsoft Active Directory; and finally configuring the SAP WebAS Java application server to use Kerberos for authentication.

Windows Domain Controller and KDC For my environment I had to create a Windows network that I could use for a sandbox. I’m assuming for the sake of this paper that most environments using Windows workstations already have a Windows network and domain controller configured. Since Windows network administration is beyond the scope of this paper, I will not be


discussing how to configure a Windows network. For more information on Windows networks see http://technet.microsoft.com/en-us/network/default.aspx Fortunately Kerberos is the default mechanism used for authentication in a Windows network domain. So by default my Windows domain controller is also a Kerberos KDC.

Network Authentication Server and Enterprise Identity Mapping Once the Windows domain was created and all of the Windows workstations added to the domain, I began configuration of the i5/OS machines in my environment. EIM and NAS were configured on each i5/OS system. I configured one i5/OS as my EIM domain controller and configured all of the other systems to join that domain. The configuration of EIM and NAS are closely related. The configuration for both services is done through wizards available through iSeries Navigator. To configure EIM and NAS: 1. Open iSeries Navigator 2. Under My Connections, select the system to be used as the EIM domain controller 3. Expand Network, then Enterprise Identity Mapping 4. Right click Configuration, then select Configure to start the wizard, see figure 2

Figure 2 Starting the EIM wizard 5. At the first dialog screen, select “Create and join a new domain” and click next, see figure 3.


Figure 3 Creating a new EIM domain 6. On the next dialog screen select “On the local Directory server” and click next. 7. When prompted to configure NAS, click “Yes” and press “Next”. Configure NAS 8. Click next to continue and start the NAS wizard 9. Enter the name of your Kerberos default realm and make sure to check the box specifying that Microsoft Active Directory is used for Kerberos authentication 10. Enter the name and port for your KDC, this should be the fully qualified domain name of your Windows domain controller. The default port for the KDC is 88. 11. When prompted to configure the system to use a password server for the default realm, select “Yes” and specify the fully-qualified host name of the KDC. The default port the password server is 464. 12. On the next dialog you will be prompted to select services for the keytab. A keytab file is used to securely store a service principal’s long term key. (With Kerberos it is possible to authenticate with a service such as an HTTP server. The service principal is the Kerberos name for that service.) Check all of the services and press “Next”. 13. The next few dialogs will prompt you to enter a password for each service. This password is used to create the keytab entries specified in the previous dialog. 14. After entering passwords for all of the keytab entries, you will be asked if you want to create batch file that can be run on your KDC host. This batch file will contain the Windows commands necessary to configure the service users. Specify yes and the location for this batch file and press “Next”.


15. NAS configuration is now complete on the server. The batch file that was created as part of the NAS wizard, must be run on the KDC host from the command prompt. Once NAS configuration is complete, the EIM wizard will automatically resume. Complete EIM Configuration 16. In the next dialog, you will be prompted to configure the directory server. The default port for the directory server is 389. Enter the value “cn=administrator” for “Distinguished name”. Click “Next”. 17. You will now be prompted to specify a name for you EIM domain. This can be any name you want. I used the value deptggqEimDomain for my EIM domain name. After specifying a name, click “Next”. 18. In the next dialog you will be asked if you would like to specify a parent DN for the EIM domain, select “No” and click “Next”. 19. You should see a warning asking if you would like to restart the directory server, press “Yes”. 20. Next you will be asked to specify user registries. Check the box for “Local i5/OS” and “Kerberos”. For the local i5/OS registry, this should be the fully qualified domain name of the server that EIM is being configuring on. For the Kerberos registry, this should be the fully-qualified domain name of the KDC. Leave the “Kerberos user identities are case sensitive” box unchecked. Click “Next”. 21. Specify the EIM system user in the next dialog. From the pull down menu select “Distinguished name and password”. For the distinguished name enter “cn=administrator”. Specify a password, press “Verify Connection” to test and then click “Next”. 22. The final dialog screen will present a summary. Verify that everything is correct and press “Finish”. NAS and EIM must be configured on the remaining i5/OS systems in your network. The same wizards can still be used, but instead of creating a new EIM domain controller, select “Join an existing domain” to join the EIM domain that you previously created, see figure 4.


Figure 4 Joining an existing EIM domain For more detailed information on configuring EIM and NAS see “IBM Systems – iSeries: Security, Single signon, Version 5 Release 4”. This can be downloaded at http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzamz/rzamzsso.htm After configuring EIM and NAS on all of my i5/OS systems, I was able to use EIM to map each user’s profile on each system to one single user ID. Once this was complete, I modified the user profiles on i5/OS so that the password field was set to *NONE, effectively eliminating the passwords. After configuring iSeries Navigator to use Kerberos, the users are now able to access any i5/OS in my network using their Windows user ID and password, regardless of their user profiles on a particular i5/OS system. To configure iSeries Navigator to use Kerberos do the following: 1. Open iSeries Navigator and expand “My Connections” 2. Right click the system you wish to modify and select “Properties” in the pop up menu 3. Select the “Connection” tab 4. Under “Signon information” select the option “Use Kerberos principal name, no prompting” 5. Click “OK”

Using Microsoft Active Directory as a WebAS Java Data Source One tactic that can be used for part or even all of your SSO solution is to centralize both user IDs and passwords. Depending on the complexity of your organization and the applications being used, this may be a good choice, especially if user IDs are


synchronized for each user and the user store data source can be configured. I chose somewhat of a hybrid solution, where I centralized the SAP application users and the Windows users. My i5/OS users were not centralized, so I used EIM to map user IDs and eliminate the passwords. Since most of my users have the same user ID on Windows as they have on SAP, I was able to easily configure the SAP user store to use Microsoft Active Directory as a data source. This provided centralization for my Windows and SAP user IDs and allowed me to administer passwords for all of these users from one central location. In cases where one user has one user ID for the Windows domain and a different one for SAP, it was necessary to synchronize the user IDs. Another possible solution is to implement an identity mapping technology such as IBM EIM. In addition to providing a centralized location to administer and maintain user IDs, the configuration of the SAP user store to use Microsoft ADS transfers user authentication from the SAP application to the Windows. This does not eliminate the user store from the SAP application since the SAP application still requires a user store for authorization. Password maintenance for all users is done on the Windows domain controller, while other user ID administration, such as assigning roles and authorities remains on the SAP application. More information on configuring the WebAS Java User Management Engine (UME) to use alternate data sources can be found in SAP note 718383 “NetWeaver: Supported UME Data Sources and Change Options” and in the SAP Library at http://help.sap.com. Search for the topic “LDAP Directory as Data Source”. For a list of SAP certified LDAP directory servers that can be used as a data source, see SAP note 983808 “Certified LDAP directory servers”. To configure the SAP WebAS Java UME to use Microsoft Active Directory as a data source, follow these steps: 1. Start the WebAS system 2. From your browser, enter the URL for the WebAS Java main page (http://<host>:5<nn>00, where host is the host name of the WebAS Java application server and nn is the instance number) 3. Click the “User Management” link and logon as administrator if prompted 4. Click “User Management Configuration” 5. Click “Modify Configuration” 6. Change the data source by using the pull down menu and update the data source file name, see figure 5.


Figure 5 Configuring the user store data source 7. Click “Save All Changes” 8. Select the “LDAP Server” tab 9. Enter the required information for each field, see figure 6.


Figure 6 Configure LDAP server for user management engine 10. Click the “Test Connection” button to verify 11. Click “Save All Changes” 12. Restart WebAS Java

Configure the UME Data Source for Kerberos Configuring the UME to use Microsoft Active Directory as a data source is only part of the necessary configuration for SSO. The UME data source must still be configured for Kerberos authentication. This is done by modifying the UME configuration XML file to map Kerberos attributes to the proper attributes in the data source. More details on configuring the UME can be found in the SAP Library at http://help.sap.com. Search for the topic “Configuring the UME when Using ADS Data Sources for Kerberos”. To configure the UME data source for Kerberos, follow these steps: 1. Start the WebAS system 2. From your browser, enter the URL for the WebAS Java main page 3. Click the “User Management” link and logon as administrator if prompted 4. Click “User Management Configuration” 5. Click the “Download File” link, see figure 7.


Figure 7 Download XML data source configuration file 7. Save the XML file so that you can edit it 8. Edit the XML file by defining the attributes “kpnprefix”, “krb5principalname” and “dn” in the “responsibleFor” section of the configuration file. See figure 8. In the “attributeMapping” section set “kpnprefix” to the physical attribute “samaccountname”; “krb5principal” to “userprincipalname”; and “dn” to “distinguishedname”. See figure 9.


...

<responsibleFor>...

<principal type="user"><nameSpaces>

<nameSpace name="com.sap.security.core.usermanagement"><attributes>

<attribute name="firstname" populateInitially="true"/><attribute name="displayname" populateInitially="true"/><attribute name="lastname" populateInitially="true"/><attribute name="fax"/><attribute name="email"/><attribute name="title"/><attribute name="department"/><attribute name="description"/><attribute name="mobile"/><attribute name="telephone"/><attribute name="streetaddress"/><attribute name="uniquename" populateInitially="true"/><attribute name="kpnprefix"/><attribute name="krb5principalname"/><attribute name="dn"/>

</attributes></nameSpace>

<nameSpace name="com.sap.security.core.usermanagement.relation"></principal>...

</responsibleFor>

...

<responsibleFor>...

<principal type="user"><nameSpaces>

<nameSpace name="com.sap.security.core.usermanagement"><attributes>

<attribute name="firstname" populateInitially="true"/><attribute name="displayname" populateInitially="true"/><attribute name="lastname" populateInitially="true"/><attribute name="fax"/><attribute name="email"/><attribute name="title"/><attribute name="department"/><attribute name="description"/><attribute name="mobile"/><attribute name="telephone"/><attribute name="streetaddress"/><attribute name="uniquename" populateInitially="true"/><attribute name="kpnprefix"/><attribute name="krb5principalname"/><attribute name="dn"/>


<nameSpace name="com.sap.security.core.usermanagement.relation"></principal>...

</responsibleFor> Figure 8 Add Kerberos attributes to UME configuration file ...

<attributeMapping>...

<principals><principal type="user">

<nameSpaces><nameSpace name="com.sap.security.core.usermanagement">

<attributes><attribute name="firstname">

<physicalAttribute name="givenname"/></attribute><attribute name="displayname">

<physicalAttribute name="displayname"/></attribute><attribute name="lastname">

<physicalAttribute name="sn"/></attribute>...

<attribute name="kpnprefix"><physicalAttribute name="samaccountname"/>

</attribute><attribute name="krb5principalname">

<physicalAttribute name="userprincipalname"/></attribute><attribute name="dn">

<physicalAttribute name="distinguishedname"/></attribute>


...

</nameSpaces></principal>

</principals></attributeMapping>...

...

<attributeMapping>...

<principals><principal type="user">

<nameSpaces><nameSpace name="com.sap.security.core.usermanagement">

<attributes><attribute name="firstname">

<physicalAttribute name="givenname"/></attribute><attribute name="displayname">

<physicalAttribute name="displayname"/></attribute><attribute name="lastname">

<physicalAttribute name="sn"/></attribute>...

<attribute name="kpnprefix"><physicalAttribute name="samaccountname"/>

</attribute><attribute name="krb5principalname">

<physicalAttribute name="userprincipalname"/></attribute><attribute name="dn">

<physicalAttribute name="distinguishedname"/></attribute>


...

</nameSpaces></principal>

</principals></attributeMapping>...

Figure 9 Map Kerberos attributes to physical attributes in UME configuration file 9. Return to the WebAS Java browser session


10. In the “File Upload” field enter the location of the edited XML configuration file 11. Click “Upload File”, see Figure 10.

Figure 10 Upload XML data source file after editing 12. Restart WebAS Java application server for the changes to take effect.

Enabling SAP Java Application Server for Kerberos SAP WebAS Java makes it possible for Kerberos authentication when using web clients such as a web browser. This is done with the Java implementation of the Simple and Protected GCC API Negotiation Mechanism, known as SPNego. The SPNego implementation for SAP WebAS Java is available as a download through SAP note 994791 “SPNego Wizard”. Besides documentation, this note includes a wizard that simplifies the configuration.

Deploy the SPNego Wizard Before using the wizard, it is necessary to deploy the wizard to the WebAS Java application server. Follow these steps to deploy the wizard: 1. Start WebAS Java 2. Connect Visual Administrator to your WebAS Java system 3. Expand Server -> Services 4. Click “Deploy”


5. In the right-hand pane, make sure the “Runtime” tab is selected 6. Press the “Deploy & Start” button, see figure 11.

Figure 11 Starting the deploy process 7. In the “File” field enter the path to the EAR to be deployed and press OK, see figure 12.


Figure 12 Deploy component of SPNego wizard 8. A warning dialog will appear, click OK 9. Click OK to acknowledge the application overwriting check 10. Click OK at the deploy dialog 11. Repeat for the remaining EARs

Run the SPNego Wizard Before running the SPNego wizard the following conditions must be met:

Microsoft Active Directory must be configured and running as the KDC Service principal name (SPN) created for the DNS name that is used to access the

WebAS Java with Kerberos authentication (service principal names and the appropriate mapping should have been configured as part of the NAS configuration)

the UME configured to use Microsoft Active Directory as the data source the UME configuration file modified for Kerberos authentication

Once the prerequisites have been met, you can run the SPNego wizard by doing the following:


1. Start WebAS Java 2. From a web browser enter the URL http://<host>:5<nn>00/spnego, where host is the host name of the WebAS Java application server and nn is the instance number 4. Logon as administrator if prompted 5. On the first dialog make sure the boxes “Service user is created and configured in Active Directory” and “UME configuration includes SPNego specific settings” are both checked and press “Next” 6. In the second dialog enter the name of your Kerberos realm and press the “Add KDC” button 7. Enter the host name or IP address of your KDC in the pop-up dialog and make sure the port number is correct and press OK 8. Fill in the required fields and press “Next”, see figure 13.

Figure 13 Using SPNego configuration wizard to specify Kerberos realm 9. On the next dialog screen select “prefixbased” from the pull down menu. 10. Take the default values and press “Next”, see figure 14.


Figure 14 Using SPNego wizard to specify resolution mode 11. On the next dialog take the default values and press “Next” 12. On the final dialog screen, validate that the values are correct and press “Finish” 13. Restart WebAS Java

Allow WebAS Java to Authenticate Using SPNego After SPNego has been configured the final step is to allow WebAS Java to authenticate using SPNego. This is done by doing the following: 1. Start WebAS Java 2. Connect Visual Administrator to your WebAS Java system 3. Expand Server -> Services 4. Click “Security Provider” 5. Select the “Runtime” tab, then the “Policy Configurations” tab, and finally the “Authentication” tab 6. In the “Components” pane, select “ticket” 7. Click the edit icon 8. Using the pull down menu, change “Authentication template” to “spnego”, see figure 15.


Figure 15 Configure WebAS Java for Kerberos authentication 9. Repeat for component sap.com/tc~sec~auth~examples*sec_form 10. Restart WebAS Java

Configure Browser The final step is to configure your web browser to access SAP WebAS Java using Kerberos authentication. Steps for doing this can also be found in SAP note 994791 “SPNego Wizard”. The following steps are for Microsoft Internet Explorer®. 1. Open your browser 2. From the menu select “Tools” -> “Internet Options” 3. Select the security tab 4. Select “Local intranet” 5. Click the “Sites” button 6. Enter the fully qualified domain name for the WebAS Java host, see figure 16.


Figure 16 Adding WebAS Java website to trusted zone 7. Click the “Add” button 8. Click “Close” 9. Select the “Advanced” tab 10. Make sure the “Enable Integrated Windows Authentication” box is checked, see figure 17.


Figure 17 Enabling integrated Windows authentication 11. Click “OK” You are now ready to test your SSO configuration!

Results and Conclusion Finally after implementing all of the pieces of the SSO solution, it is time to bring it all together. Our user John will still sign-on to his workstation first thing in the morning. Since John has already authenticated he can access any resource in the enterprise without entering his credentials again, see figure 18. More importantly, John no longer has to keep track of multiple user IDs and multiple passwords. This makes life a lot easier for John, especially when he is forced to change his password on a regular basis. Since John only has one password to remember, he no longer has to write down his passwords and leave them somewhere easily accessible. John is happy and the help desk and administrators are happy because the volume of calls relating to password problems has dropped drastically.


Figure 18 Simple enterprise environment with a single point of access after SSO The goal is to reduce administrative costs and improve security through the use of SSO. Eliminating user ID and password prompts, though convenient for a user, is not the primary purpose of SSO. However, it is usually a positive side effect of some SSO implementations. SSO is not a product that can be installed and configured, but rather a custom solution that can include different products and technologies as well as incorporate different strategies. The approaches to implementing an SSO solution are as varied as the technologies and products that can be utilized. So to sum it all up, there is no “one size fits all” solution for SSO and to make use of another cliché common in IT when it comes to implementing SSO, “it depends.” I have shown one approach to expanding SSO from an SAP on i5/OS landscape to the entire enterprise. Hopefully, this will provide some valuable insights when planning an SSO solution for your environment. All of the technology that I used was either part of Windows, i5/OS, or made available by SAP. In this simple case, no third party SSO technology was necessary, although a number of vendors do offer SSO enabling technology. Armed with this information and the knowledge that SSO is indeed a possibility in your SAP on i5/OS environment, you can begin developing an SSO strategy and plan suited for your enterprise.

Windows 2003 Active Directory

Legacy application on i5

SAP Enterprise Portal on i5

SAP backend systems

John Smith's user IDs: u:jsmith p:myonepwd u:jsmith p:none u:johns p:none u:smithj p:none etc..


References Garman, Jason. Kerberos: The Definitive Guide. 1st edition, Sebastopol, CA: Farnham: O’Reilly 2003. International Business Machines Corporation. IBM System i and i5/OS Information Center: Enterprise Identity Mapping (EIM). <http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzalv/rzalvmst.htm?resultof=%22%45%/>. International Business Machines Corporation. IBM System i and i5/OS Information Center: Network Authentication Service. <http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzakh/rzakh000.htm?resultof=%22%/>. International Business Machines Corporation. System i Security, Single signon, Version 5 Release 4. Third edition, 2006. <http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzamz/rzamz.pdf/>. Massachusetts Institute of Technology. Kerberos: The Network Authentication Protocol. <http://web.mit.edu/kerberos/>. Microsoft Corporation. Windows Server 2003 Active Directory. <http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx/>. Microsoft Corporation. Microsoft TechNet: Networking and Access Technologies. <http://technet.microsoft.com/en-us/network/default.aspx/>. SAP AG. SAP Help Portal. <http://help.sap.com/>. SAP AG. SAP Note 718383 “NetWeaver: Supported UME Data Sources and Change Options”. SAP AG. SAP Note 983808 “Certified LDAP directory servers”. SAP AG. SAP Note 994791 “SPNego Wizard”.

Documents

Expanding Single Sign-on for SAP Landscapes on i5/OS...Expanding Single Sign-on for SAP Landscapes on i5/OS Page 4 of 26 Environment To illustrate SSO, I implemented a simple environment