SPNegoLoginModule configuration for multi-forest scenarios with SUN JDK

Transcription

1 SDN Contribution SPNegoLoginModule configuration for multi-forest scenarios with SUN JDK Applies to: SAP NetWeaver 04 Java Stack as of SPS15 Summary This document explains how to configure Windows Integrated Authentication with the SPNegoLoginModule in a Windows environment with two separate, in no way related Windows Active Directory Forests. Author(s): Kai Ullrich Company: SAP Deutschland AG Created on: 3 August 2006 Author Bio Kai started working in the basis development of SAP in In 2001 he became Development Architect in the newly founded company SAPPortals. In January 2005 he joined the German Consulting subsidiary SAP Deutschland AG as a Senior Consultant. His focus are security and user management topics in the Java Stack of NetWeaver. He is the author of the initial version of the SPNegoLoginModule which is available in the standard NetWeaver as of SPS SAP AG 1

2 Table of Contents Introduction... 3 A use case... 3 Configuration... 3 Related Content... 7 Disclaimer and Liability Notice SAP AG 2

3 Introduction Since it has become part of the standard as of SPS15 of SAP NetWeaver the Windows Integrated Authentication or so called SPNego authentication has seen a growing success. A large number of customers have installed the solution, benefiting from more usability and decreased maintenance costs. However, there is one topic that the official docs on help.sap.com don t say a single word about and that an increasing number of customers are asking about: The configuration of Windows Integrated Authentication with more than one Windows Forest. A use case I recently came across such a situation where a customer (an IT service company) wanted to set up an Enterprise Portal for 3 or 4 of their customers. Each customer has an own AD forest, trusts between those forests not extant and/or not desired. All user accounts of these customers were replicated into a kind of meta-directory which served as UME datasource for the NW Java Stack (see Figure 1). Figure 1: Landscape with a NW04 installation and two AD forests The customer s intention was to set up SPNego authentication for each of the forests. Obviously this requires some kind of multi forest setup. The documentation describes how to set up something like this with one AD forest but what about 2 or more? Since more and more situations come up where this kind of setup is desired I decided to publish something about this on SDN. The configuration is quite straight forward and solves the problem; however there are some minor drawbacks you need to live with. The fundamental difference to ordinary scenarios is that there is more than one Kerberos realm and the configuration on NetWeaver needs to take this into account. Configuration First step is that you need to tell NetWeaver the kdc and admin_server of all domains. So for example purposes let s suppose we want to do the configuration with two domains called SUPPLIER.NET and 2006 SAP AG 3

4 MANUFACTURER.CORP. If you have studied thoroughly the SPNego config guide on help.sap.com you will conclude that the necessary modifications need to be executed in the krb5.conf file which tells the Java Kerberos implementation ip address or host name of the Kerberos KDC. After the modification the [realms] section of the krb5.conf file looks like this: [realms] SUPPLIER.NET = { kdc = admin_server = } MANUFACTURER.CORP = { kdc = admin_server = } Each of the two sections tells the Java Kerberos implementation at which address it can find the Kerberos servers for the respective domains. The next question is how to configure the com.sun.security.jgss.accept login module stack. Until now, it was responsible for acquiring the Kerberos credentials for a Kerberos Realm. Now we have two realms, don t we need two stacks? Well, yes and no. Obviously we have two different keytab files coming from two different Kerberos Realms and we somehow need to deal with that. But there is only one stack and we can t duplicate it. But there is another thing we can do. We can add an additional Krb5LoginModule to this stack. The first Krb5LoginModule will deal with the first Realm, keytab and so on and the second one will deal with the second Realm, keytab So after making krb5.conf and the two keytab files ready (let s call them keytab.supplier and keytab.manufacturer) the stack com.sun.security.jgss.accept looks as follows: Krb5LoginModule REQUISITE debug=true principal=...@manufacturer.corp donotprompt=true storekey=true keytab=/usr/sap/sid/jc00/sec/krb5/keytab.manufacturer useticketcache=true usekeytab=true refreshkrb5config=true Krb5LoginModule REQUISITE debug=true principal=...@supplier.net donotprompt=true storekey=true keytab=/usr/sap/sid/jc00/sec/krb5/keytab.supplier useticketcache=true usekeytab=true refreshkrb5config=true MappingModule OPTIONAL com.sap.spnego.uid.resolution.attr=krb5principalname Please note that in contrast to what is documented on help.sap.com this configuration needs the refreshkrb5config=true parameter SAP AG 4

5 Figure 2: com.sun.security.jgss.accept stack with two Krb5LoginModules What happens when the J2EE Engine is trying to acquire credentials? First of all, it runs through the stack com.sun.security.jgss.accept, which is the stack above. It executes each login module. Each of the Krb5LoginModules is executed and if configured properly, it reads the keytab file, reads the key in it and adds the principal/key pair to a kind of internal status. This way keys for the principals from the two Kerberos Realms MANUFACTURER.CORP and SUPPLIER.NET are available, which is mandatory for what we want in our scenario. Making keys available is one thing but there is still one thing missing that is not less fundamental. We somehow need to enable SPNego authentication from the two Kerberos Realms. The easiest way to do that is to define two authschemes each of which will use a separate SPNego configuration. So we define an additional authscheme in authschemes.xml that points to a login module stack called spnego, too SAP AG 5

6 Figure 3: spnego authscheme definition in authschemes.xml The spnego login module stack is a copy of the ticket login module stack with some slight modifications. Here we can use the standard SPNego login module stack with SPNegoLoginModule and BasicPasswordLoginModule that is also described on help.sap.com. EvaluateTicketLoginModule SUFFICIENT ume.configuration.active=true SPNegoLoginModule OPTIONAL com.sap.spnego.jgss.name=...@supplier.net CreateTicketLoginModule SUFFICIENT ume.configuration.active=true BasicPasswordLoginModule REQUISITE CreateTicketLoginModule OPTIONAL ume.configuration.active=true Figure 4: ticket login module stack EvaluateTicketLoginModule SUFFICIENT ume.configuration.active=true SPNegoLoginModule OPTIONAL com.sap.spnego.jgss.name=...@manufacturer.corp CreateTicketLoginModule SUFFICIENT ume.configuration.active=true BasicPasswordLoginModule REQUISITE CreateTicketLoginModule OPTIONAL ume.configuration.active=true Figure 5: spnego login module stack Figure 6: ticket login module stack in Visual Administrator 2006 SAP AG 6

7 Figure 7: spnego login module stack in Visual Administrator Please notice Figure 4 to Figure 7. It shows the two stacks once in Visual Administrator once in detail with all options. Note that the only difference between the ticket stack and the spnego stack is the different com.sap.spnego.jgss.name Parameter. Its values correspond to the values of the principal parameters in the Krb5LoginModule of the com.sun.security.jgss.accept stack. This parameter tells the login module which credentials to use. The ticket stack is configured to use the Kerberos credential from the SUPPLIER.NET realm and the spnego stack uses the credential from the MANUFACTURER.CORP realm. To summarize it, we have two completely distinct authentication configurations. One is the authscheme default which references the authentication template ticket. The default authscheme is always there and used for the portal logon by default. As additional authscheme we have added an authscheme called spnego which references an authentication template that is also called spnego. The only thing that remains to say is how we trigger the SPNego authentication. The easiest way (which has some drawbacks) is to have two URLs. Users from SUPPLIER.NET call and users from MANUFACTURER.CORP call 1. The first URL does not contain any special authentication information so the default authentication configuration is used. The second URL tells the portal to run the authscheme spnego, so the login module stack from Figure 5 is executed. For users in the SUPPLIER.NET realm the SPNego token being sent from the browser is encrypted for the service user from SUPPLIER.NET. The value of the com.sap.spnego.jgss.name parameter tells the SPNegoLoginModule to use the correct credentials. Same thing on the MANUFACTURER.CORP side. Well, to come back to the beginning: Now our customer can simply configure two static html pages (similar to /irj/index.html) containing redirects to the two URLs. Users from SUPPLIER.NET get the first, users from MANUFACTURER.CORP the second page as portal entry page. As a result, for all users the correct configuration is used and all benefit from the advantages of SPNego authentication. Related Content The following links to content on help.sap.com explain notions used in this article. 1. Login modules and login module stacks 2. Using Kerberos Authentication for Single Sign-On 3. SPNego Protocol Introduction 1 Beside the fact that we need two URLs another drawback is that the URL parameter remain in the URL. Some additional fine-tuning would be necessary to solve this problem SAP AG 7

8 Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document SAP AG 8