While we are a long time user of EntireX, utilising ACI calls between z/OS LPARS, we are newcomers to the realm of using it to expose the mainframe to the Java world. Our proof of concept project (browser → Java app → EntireX wrapper → Broker → Natural RPC) is working nicely but, as we move beyond the sandbox, we have started to consider things like security.
We are looking to implement EntireX Security and we are keen to have a single sign on so that users of the browser app won’t need to enter their mainframe password (same userid but potentially different LAN password). ACF2 will accept a generated passticket instead of a password so that seems to be the way to go.
IBM publishes its passticket generation algorithm and I’ve scoured the web looking for an example written in Java but haven’t been able to find one.
Before we head off to reinvent the (passticket) wheel, can anyone help us and share one they prepared earlier?
Hi Graeme
These are 2 distinct issues - SSO vs Passticket. Here is high level RoadMap:
With SSO you need the Windows user to be defined in ACF2, and somehow transparent to the application the Windows user passed under the cover to ACF2 which will treat it as already verified. There is no such thing, it’s complex. I presumed Windows for example.
With passticket - your Java code can use a Java routine to generate the passticket - and pass it to Natural which must have Security Interface to ACF2 (its a separate feature/product, I forgot it’s name). With RACF I know for sure - RACF will take the password and first check it as password, if not will check it as passticket; not sure about ACF2. So passticket will work - and it may satisfy your needs - call it as you like.
Clarification
Java client t generating passticket is EEX client - will pass passticket in RPC password field according to EXX protocol, and Natural needs not know that it is a passticket; Natural just passes it to Security Product as password.