cancel
Showing results for 
Search instead for 
Did you mean: 

Delegated credentials to call RFCs via SAP JCo

oliver-itm
Discoverer
0 Kudos
270

Hello, i found some hints in answers.sap.com but nothing helped me.

The situation is this: I have a JEE application with Tomcat as servlet-container using Java 8.
I followed https://spnego.sourceforge.net/ to set up Kerberos-Authentication with delegation of credentials.
(Just for completeness: For using Edge as Browser I had to add a registry-entry to make delegation possible.)

In the last step i now have:

assert httpRequest instanceof DelegateServletRequest == true;
DelegateServletRequest dsr = (DelegateServletRequest) httpRequest;
GSSCredential gssCredential = dsr.getDelegatedCredential();
Subject subject = GSSUtil.createSubject(gssCredential.getName(), gssCredential);

The Subject-Instance explicitly contains the UPN (User Principal Name) of the signed in (delegated) user. (myuser@MYDOMAIN.DE)Now I use the Subject-Instance to change the identity like this:

Subject.doAsPrivileged(subject, action);

The 'action' contains the build of the destination including the destination-properties and calling destination.getAttributes().

The connection to SAP is built up using SNC! Setting the SNC-properties accordingly.

The Username/Password properties remain empty.

The property 'jco.client.snc_myname' contains: "p:CN=myuser@MYDOMAIN.DE".

I expected the SAP-call to be executed as the delegated user. But the sap-call always is executed as the account the Tomcat runs under.

How can I hand over the Kerberos-Ticket to the SAP JCo?

Googeling around I found nothing concrete. But I now guess, the Kerberos-Ticket has to be stored in the mslsa-Ticket-Cache on the java-side. And on the 'sapcrypto.dll'-side the ticket is fetched from the cache by using the 'jco.client.snc_myname'-property. But in the current versions of Windows the 'Credential Guard' prevents saving the ticket in the mslsa.I don't know how to go on from here.

Please help, I spent several days to find a solution.

Accepted Solutions (1)

Accepted Solutions (1)

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert

> How can I hand over the Kerberos-Ticket to the SAP JCo?

The answer is: you can't. In the SNC case (at least when SNC is also used for authentication and not only for encryption+user&pwd-logon), JCo is not involved in the authentication process. You would have to pass the Kerberos-Ticket to the SNC library.

But here is the next problem: I see you are using sapcrypto.dll as SNC lib. This one does not use Kerberos, it uses an X.509 certificate based authentication mechanism. So first you would have to find a Kerberos-based SNC lib implementation, for example the one described in note 2115486.

And next you need to consider: which SNC lib is the SAP backend system using? You cannot simply use a Kerberos-based SNC lib on JCo side, if the backend side uses the certificate-based sapcrypto.dll... The two sides would not understand each other... 🙂 So first action item is: check which SNC implementation your backend us using.

Finally, there is another login mechanism that might be used for Kerberos tickets, but it's out-dated and not to be recommended: you could use SNC only for encryption (let's say sapcrypto.dll on both sides) and then use the EXT_ID logon mechanism for transporting the Kerberos ticket to the backend side. Here you would have to setup a mapping between Kerberos ticket and SAP User, I think in transaction EXTID_DN. (A few different types of "external IDs" are supported here, and I think things like Kerberos tickets, SPNEGO or Windows domain users are among them, but I'm not 100% sure. It will also depend on the SAP system release.)

SAP note 150380 might provide additional interesting details on SAP & Kerberos.

oliver-itm
Discoverer
0 Kudos

Thank you for answering so quick.

For the use of SSO via Kerberos and SAP JCO the information is simply too thin.

I can't find any information about EXT_ID. And of course we don't want to use anything that will not be supported in the foreseeable future.

So only a X.509 client certificate remains.

Thank you very much for your efforts.

Answers (0)