I'm curious how much interest there is in this. Due to the history SAP has of making a new strategic UI programming model switch every 4 years (ITS, Java WD, Abap WD, SAPUI5/Fiori, ????), I have always tried to use more open source and Java standard solutions for our SAP web applications. This worked well since the Netweaver Java system up until and icluding Netweaver 74 implemented the full Java EE profile. We use EJB3.0, JSF 2.1.x, JPA via EclipseLink etc. in our bolt on SAP solutions.
Since it seems evident that SAP is now positioning Netweaver Java as more of a thin layer of UI for proprietary SAP technologies vs. a full Java EE server, I started looking at what it would take to move to something like Glassfish or Wildfly for our SAP applications.
Here are some obstacles, and some parts of a solution. Would love if others have anything to contribute!
SAP Netweaver java makes the following credential flow really simple. LDAP/AD/Abap user store -> UME -> user mapping to ABAP system -> SSO2 cookie generation -> web container to EJB container credential passing -> EJB to SAPJRA resource adapter credential passing -> user logged onto back end Abap stack as themselves.
- SAP SSO - To my knowledge, the only systems capable of creating SAP SSO2 cookies are Netweaver Java and Abap stacks. The sapjco3 only supports Userid/Pw, x509, or SAP SSO2 cookies for logon to the back end system. Ideally I'd like to use SAML2 to directly call an RFC through the sapjco (or sapjra), but I don't think this exists. Does anyone have a solution here?
We have at least 1 application which requires a persistent state from our java app to the Abap back end (the way sap implemented a standard RFC is that it will fail if you call it a second time and the user is logged off already, so the user's session has to remain open after the first call). For this reason, I think we need sapjco native calls, could and RFC converted to a web service retain the users's state between calls?
Some really nice open source projects which offer parts of a solution:
- Cuckoo Resource Adapter for SAP Cuckoo Resource Adapter for SAP / Home / Home
- This hasn't had any code changes for the last 3 years, but I was able to easily get it working from Wildfly 9
- The code only supports hard coded username/password, no SSO2 tickets. Even if it supported SSO2 tickets, how could I generate one without bouncing a redirect off of a Netweaver java system (which would defeat the purpose)?
- Jboss-sap-jca punkhorn/jboss-sap-jca · GitHub
- Also no code changes for 3 years, haven't gotten it working in Wildfly, but spent less time with it
- Seems to support SSO2 logon by looking at the code, but again, how would it get generated?
- Hibersap Hibersap home From the same creator of the Cuckoo Resource Adapter for SAP, has had more recent activity, and seems really impressive to reduce boilerplate code calling RFC's.
The challenge is - without Netweaver java - how do we do user mapping from a non SAP java server to the Abap stack using SSO? I think ideally I'd like to use SAML2 assertions, but there isn't any way I can think of to get that user to be recognized and logged onto the Abap stack. I guess one solution potentially would be to use a communications user hard coded in the resource adapter, and pass in the SAP username as a parameter to a "wrapper" rfc, but that is less than ideal for multiple reasons.
Hope others have interest in this subject too!
Chris