Open Source Alternatives to Netweaver Java

[Former Member]

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

[rolf_paulsen]

Hi Chris,

as you can see in the "When will SAP Java AS for EE 6 see the light?", there are others who are interested.

Concerning SAP's UI (UX?) strategy: at least the open source contribution and building UI5 on open Framework jQuery and standards HTML5 / OData not invented by SAP is a new quality compared to the predecessors you mention. But you are right that SAPUi5/OpenUI5 will only be adapted by SAP customers. Open source contribution will be irrelevant compared to other widely accepted frameworks like angularJS. Furthermore jQuery and in general the templating approach are somehow "over the hill" already. We cannot expect that current enterprise trends like Typescript (microsoft) or pure declarative DOM manipulation (e.g. angularJS, google) will find a way into SAPUI5/Fiori. Again: a mostly SAP proprietary framework with all the consequences e.g. direction towards proprietary tools like Web IDE instead of open Eclipse plugins.

Concerning your main topic: this is no current question since Java 8 support in NW 7.50 is a very important step for the next years, but I keep an eye on it midterm

The replacement of UME integration, production of SSO2 token by Java server itself, was my first obstacle considering a move to another Java EE platform, and there is promising input for this. In the HANA Cloud Platform all these topics are solved based on Tomcat EE (the base of HCP development). Maybe we can copy something from there, maybe Tomcat EE will also become the next generation on premise Java platform? Cloud first approach in Java EE?

As far as I know SAML2 tokens are supported both by ABAP and non-SAP application servers and SAML2 is also supported in the cloud, but I am no expert, sorry in advance for any confusion.

Another topic: Will we be able to run our WD Java applications outside AS Java? Very unlikely, but not impossible. There was a Tomcat version of WD Java Demokit in Netweaver 7.20 and a few years ago I took some research to get a simple WD EJB model running on this base on JBoss.

I remember that I had to copy half the AS Java appserver jars into JBoss lib directory...not too promising for production use.

So probably going away from AS Java means abandon WD Java.

Concerning BPM, there are powerful frameworks like JBoss drools that probably fill the gap without too much trouble.

Regards

Rolf

[daniel_ruiz2]

hi Chris,

You can use any IdP in order to have your user authenticated and then only reverse the SSO cookie generation code to spit out a valid Cookie.. shouldn't be too hard to get that going.

As soon you have your cookie you stop using function modules - Expose your functionality either in OData (which I hate btw, but it's a free world) or use SREST direct out of any back-end system. As soon you have connection over http and you use SSO in the ICF Authentication Method you're sweet.

Hope it helps,

Dan.

[Former Member]

I looked into writing code to create a SSO cookie before, didn't seem 100% straightforward to me.  Do you have any idea how to get started?  I assume I could export the cert from my open source server running my custom code to create SSO2 cookie, and import that to STRUST on the ABAP side and it should work.  Have you ever looked into this before, or were you just assuming that it should be possible?

[daniel_ruiz2]

hi Chris,

As far I'm aware you'd need to setup the ABAP to accept SSO as per normal configuration - so yeah, STRUST, etc - this will enable the ABAP to consume the ticket and of course start a session in the backend for that given ticket.

Of course, you can solve your problem in many different ways - and I would actually tell you what's more common or at least what I've seen more over the years. SAP J2EE provides a login module called HeaderVariableLoginModule - with such module you won't need to send "the password" in order to authenticate but rather just the user name.

This is nice since we don't want ABAP to Authenticate but rather your jBoss for instance (using a security-realm on LDAP let's say) - as soon you have the Principal you can send that over and acquire a Ticket.

I'm not too sure what's involved in such and I would believe sapcryptolib is in the middle and it's very likely you will need some sort of JNI into that library - but what you want is achievable and it's only a matter of you decompiling the AS sources and finding your way thru the class I mentioned.

I personally don't have a J2EE Instance that I can "break" - otherwise I would help you as it seems rather nice alternative to aging SAP software.

Cheers,

Dan.

[Former Member]

This article tells how to do it, but I still have some questions I asked there. 

This would solve the MYSAPSSO2 cookie issue... seems very promising.

[daniel_ruiz2]

hi Chris,

Not really - you could as I mentioned decompile the Java code from SAP and work out from there - you could learn far more reversing SAP's code than using an implementation in ABAP.

Give it a try, Martin Voros is in Australia timezone and he will very likely share the code with you.

Cheers,

Dan.

[former_member184549]

He has freely shared the code when I asked him - the code was simply lost with the demise of SAPs code exchange

[former_member184549]

My thinking is that you will still keep the ABAP system, and you can continue to use its User Store (especially for the case say where you had an external portal - how would you migrate your users to a new user store?).

So the ABAP stack would provide you with SSO2 tokens. Maybe I'm not following, but this part seems fairly trivial, doesn't it? Something like an HTTP handler on a SICF node that calls a function like SUSR_INTERNET_USERSWITCH or SUSR_CHECK_LOGON_DATA which will definitely return the SSO2 token?

Plus, I have had great success with the 'RFC connectors' providing username/password and also X509 certificate authentication, so the solution needn't involve you writing ABAP code to get an SSO2 cookie saved to the browser.

What though would you want your frontend to be - this is a possible opportunity to move away from the heaviness of Java and to do something lighter, like a Ruby or Python framework. Yes, legacy code may mean Glassfish, but like a lot of people I prefer the agility of scripting languages, and if you're going to go open source then why not?

I like the PyRFC connector and would think that a Django framework or Plone would be interesting.

Any thoughts?