SPNego for multi-forest using IBM JDK

Question

Hi All,
I need to setup SPNego authentication for EP7 and IBM JDK for a multi-forest landscape (2 Active directory domains).  There's a guide about how to do this for Sun JDK : https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/c771c3d3-0c01-0010-b5b6-86755a2cf778 but I need one for IBM JDK as the login stack mudules are different.
Can anyone supply me with a guide or any helpful information regarding this ?  Do you know if it works?  I've currently got SPNego working for a single domain.
Thanks in Advance,
Anthony

Answer 1

Jan,
ok, thanks. I will now explain how I think we can help.
Firstly, to be sure you understand - I represent a SAP partner company known as CyberSafe, and we have a product which uses SPNEGO for Kerberos authentication in a browser environment, so my answer relates mainly to our product functionality, and not related to the SAP login module, which has less functionality.
I must also apologise in case anybody reading this thread has an issue with me discussing non-SAP software. My view is that the most important thing on this forum is to help you (the SAP customer) get a solution that meets your needs, and if this involves SAP Partner products as well as SAP products, then that is acceptable.
Firstly, our product does not use the Java implementation of Kerberos. Instead, we use a JNI (Java Native Interface) so that our host based Kerberos library can be used to implement the protocol. This means that any differences between IBM, SUN or any other vendor JDK version related to Kerberos functionality, multi-domain support etc. are not relavent to our product. We support many things in our product which are not supported in Java implementations of Kerberos, so you don't need to wait for new versions of JDK to take advantage.
Secondly, and perhaps more relavent to this discussion is that our login module authenticates the user by decrypting the service ticket received using the key in the Key Table File on the host, and then we map this principal name onto a SAP user id. We then (via. the login module stack) cause the SAP system to issue an SSO2 logon ticket for this user id. The secret is the way we perform the mapping - we are not dependant on UME datasources for this, and I will describe below how we acheive mapping by using an example :
Lets suppose a user is authenticated as user.name@DOMAIN1, the SAP system login module has been setup using domain 2 (Realm = DOMAIN2) and trusted via a key in a key table file, with principal name of HTTP/hostname@DOMAIN2. Then, using normal Kerberos cross realm trust, and cross realm TGTs the browser requests a ticket from AD for HTTP/hostname@DOMAIN2, and this is issued by AD in domain 2 using the cross realm TGT, but the principal name of the authenticated user inside this service ticket is user.name@DOMAIN1. The login module on the SAP server can decrypt the ticket it receives to find the users Kerberos principal name.
So, the login module knows the user is user.name@DOMAIN1, it then has to decide how to determine the SAP user id. Our login module currently supports two different methods of performing this mapping, but we are adding more methods in each release to make the product even more flexible. Currently we support the following methods :
1. Simple mapping - this is where we remove the realm name and convert the principal name to upper case, so in this example user.name@DOMAIN1 would be mapped to a SAP userid of USER.NAME and used to issue an SSO2 ticket. Clearly this is only suitable for single domains, and makes administration very easy - many of our customers use this method, but you would need a different mapping method due to yoru multiple domains.
2. USRACL mapping - Since we also sell an SNC product for SAP GUI SSO, our customers already maintain mapping of Kerberos principal name to SAP user id using a table in ABAP engine called USRACL. This table is maintained using SU01 transaction. We now have support in our login module to read the USRACL table using the authenticated Kerberos principal name of the user (e.g. user.name@DOMAIN1) and find the required SAP user id, so that an SSO2 logon ticket can be issued.
I hope this helps you understand. If you are interested in more detail about our product, and how we might be able to help you, please feel free to contact me offline instead of via this forum.
Thanks,
Tim