Spnego for ABAP WAS

[Former Member]

Is somebody in SAP AG working on SPnego implementation for ABAP WAS? That is so strange when application server uses GSSAPI for GUI connection's and unable to use it for HTTP!

Is somebody help me to understand how can i fix CL_BSP_LOGIN_APPLICATION and "system" BSP for SPnego support in WAS?

[WolfgangJanzen]

No, there are no concrete plans.

Yes, I fully understand that you wish to have the same functionality for both stacks (ABAP and J2EE).

The ABAP stack has a fixed number of hard-coded "login modules". There is no such concept like "JAAS login module stacks" where you can deploy your own custom login module.

The SPNego (=> Kerberos) authentication scheme is currently not implemented in the ABAP stack (precisely speaking: in the ABAP kernel). And there is nothing you can do about it - except submitting development requests (=> documenting: there is a market demand).

Cheers, Wolfgang

[tim_alsop]

It is my understanding that SAP have chosen to provide plugin (e.g. custom login modules) support in Java Stack because JAAS is an industry standard. If they provided something similar in ABAP stack it would be considered propriatory, and not based on a well known and understood standard such as JAAS. This was the reason I was given by product management when I asked this question a few years ago, and this is why we developed the servlet that I mentioned in my last post.

Cheers,

Tim

[WolfgangJanzen]

Hi Tim,

theoretically it would be possible to implement JAAS login modules in NWAS ABAP as well - since NWAS ABAP is capable of hosting a Java VM (=> VM container).

Another challenge is:

NWAS ABAP supports more than just one protocol (http, RFC, DIAG, CPIC). JAAS login modules however are mainly used in the context of (J2EE) web servers. Unfortenately some authentication mechanisms are tightly linked to certain protocols. For example, SAML browser artifacts.

So, it might not be possible to implement something like JAAS login module stacks for NWAS ABAP replacing the current implementation. But I could imagine to enrich the current set of (hardcoded) authentication schemes by one additional (generic) authentication scheme based on JAAS login modules (implemented in Java, hosted by NWAS ABAP).

Notice: it's just an idea (of me as an individual). It's <u>not</u> a promise or "feature announcement".

[Former Member]

As I understand, in ABAP WAS used PLUGIN idea for extrental protocol's support. As I know there are two public plugin already present: for HTTP and SMTP.

I think there are not so easy with activate support for RFC4178.

There are must be changed libhttp.so (or libhttp.dll for Windows) for native support SPnego, may be changed ICM, must be changed SYSTEM BSP and class CL_BSP_LOGIN_APPLICATION. That is a hard work.

Also I can not find API specification for creating PLUGIN lib's for ICM and can not find API specifications for creating CRYPTOLIB for SAP WAS.

[WolfgangJanzen]

Please do not mix two entirely different issues:

you are right stating that the ICM has a plugin concept - for protocols (such as HTTP and SMPTP).

But that is not (directly) related to authentication mechanisms.

Regarding GSS-API (<a href="http://www.ietf.org/rfc/rfc4178.txt">RFC 4178</a>):

the ABAP stack supports GSS-API (via SNC) for the SAP proprietary protocols RFC and DIAG (=> SAPGUI), only.

As stated previously: there is no plugin concept for authentication mechanisms (like the JAAS login module concept for the NWAS Java) for NWAS ABAP. This is a first-hand information ...

[tim_alsop]

Alexey,

To handle BSP apps, and apps supported by ICF framework (e.g. webgui in Integrated ITS) with a J2EE login module, we have coded a Java servlet which calls the UME API. We then configure the ICF for the application so that a redirect goes to the servlet, the servlet then authenticates the user, causing an SSO2 ticket to be issued, and then redirects back to the application initially requested. This works well and satisfies the situation where login modules cannot be added to the ABAP stack.

Thanks,

Tim

[WolfgangJanzen]

Thanks Tim,

yes, that is indeed an option.

(Same as the "PAS" service, which however requires an external ITS).

But that mechanism has certain contraints which might prevent its usage:

The URL to access the J2EE servlet (=> JAAS login module) needs to be static (since it has to be entered in the ICF settings) and valid for all http clients. In mixed intranet/internet scenarios you either have to use different NWAS ABAP entry points (=> different ICF services) or the URL to access the J2EE servlet needs to valid for both (internet / intranet) scenarios.

Since that servlet needs to trigger an http redirect (after successful user authentication) back to the originally called URL, that redirect URL needs to be passed as URL parameter. Well, being able to instruct a server to redirect a client to an URL which can be controlled by another server bears a certain security risk ... (similiar to XSS).

Cheers, Wolfgang

[tim_alsop]

Wolfgang,

Yes, the concept is similar to how PAS modules work in external ITS.

The URL configured in ICF settings does not need to be static since ICF has functionality to pass parameters, and these can be used to construct the URL.

For security reasons our servlet only handles redirect back to the same host the request came from (e.g. login module needs to be installed on same WAS system as ICF settings are made). If it was able to authenticate and then redirect to any URL it might be open to misuse.

Note: This servlet is included with our TrustBroker Adapter product, and used by many of our customers with our login module to support webgui or BSP app integrated windows authentication.

Thanks,

Tim

[Former Member]

Thank's!!!

I don't like schema when I need to keep J2EE Engine together with ABAP instance only for authentication purposes. Especially when we don't have Java Application's in Enterprise landscape.

Redirect to JAAS module is a good solution. When we use portal. But when I don't need to "Portal" my enterprise, solution came a very expensive for implement and productive support. May be easy to drop trying to use SPnego and try to use TLS in ABAP WAS for HTTP user's.

[WolfgangJanzen]

Hi Tim,

sorry, you got me wrong: I was not referring to the URL of the ICF service which was initially requested by the browser. That one (including all its URL parameters) can be entered as ICF variable - allowing to inherit the ICF settings. I was referring to the URL of the J2EE servlet.

Yes, under the additional contraint that both, NWAS ABAP and NWAS Java, are installed on the same machine (=> Dual Stack installation) you are able to minimize the risk.

Well, finally you also managed to place your advertisement ...

Regards, Wolfgang

[tim_alsop]

To be clear, I think you are referring to the URL entered in SICF in the "Redirect to URL" field, in Logon Errors tab. Is this correct ?

Anyway, you can still use variables in this field so the full URL used to redirect to the servlet is based on hard coded info as well as variable information.

PS. Sorry I placed an advert for our product. I appreciate that these forums are not the appropriate place for that kind of info. In this case, I felt it was necessary so others know I am not refering to the SAP login module, and therefore cause any missunderstandings.

Cheers, Tim

[tim_alsop]

Alexey,

If you consider using TLS in ABAP WAS for HTTP users, then you need to consider the fact that you will not necessarily get the same as with the SPNEGO IWA approach. Let me explain... Normally the SPNEGO login module is used to implement Integrated Windows Authentication ("IWA"), e.g. the identity of the user who logged onto their workstation, and authenticated with Active Directory using Kerberos is used to get an SSO2 ticket from SAP and log them onto SAP. With a TLS based solution (unless I missunderstnad what you are proposing) you would need to have certificates for each user, and use smart card based logon to each workstation to give you IWA. Maybe you are not looking to get IWA ? If not, then I can understand why you might be considering other options to the SPNEGO module.

Take care,

Tim

[WolfgangJanzen]

Yes, we are on the same track.

Yes, you can use certain ICF variables (e.g. for the hostname of the J2EE server) as well - but only under certain contraints (here: hostname of NWAS ABAP = hostname of NWAS Java). In general that might not be possible.

Sorry, but I always (have to) have the general scenario in mind. As always in computer science: the more contraints you can assume to be valid, the better solutions you can design.

(A good design provides solutions for various scenarios)

Cheers, Wolfgang

[Former Member]

We using IWA in another configuration.

We using standalone Kerberos5 server based on RHEL4 and integrated Kerberos for Windows in logon stack of workstation. User authenticate in OpenLDAP directory in special logon window ( we don't using MS ADS). And we have properly assigned to each user Kerberos keys after login. All user application's like SAPGUI or FireFox browser, FTP client, MAIL client uses Kerberos 5 authenticate via Kerberos mechanic's. It's really SSO in elsewhere.

If you mean that SPnego I need for schema with MS ADS + IE + SAPGUI that you are wrong.

We using heterogeneous landscape with Win32 and Linux workstations. We have a little cup of productive applications. We don't have PKI infrastructure and I afraid that will be problem for us.

I know that SAP WAS allow to use X.509 certificates to authenticate user's in SAP system. That may be solution against using SPnego and SNC.

[tim_alsop]

Alexey,

If you are using a different Kerberos server for authentication instead of MS ADS, this makes no difference, for the purposes of this discussion (obviously, there are differences, but not related to how SPNEGO can be used with SAP WAS).

I am familiar with how Kerberos 5 is used in an SSO environment with many apps (e.g. browser, SAPgui, MAIL, FTP, SSH, Oracle, Sybase, etc. etc.). This is what I spend most of my life working on, as my company specialises in this. So, in summary - we are on same page when we are discussing the value of using Kerberos in a heterogenous environment.

My comment about X509 and TLS was due to the fact you mentioned using it instead of SPNEGO. My point was/is that if you do, then you need to assign an X509 certificate to each user, and the user needs to authenticate at the workstation using this certificate. Clearly you are not doing this, as you are using LDAP and Kerberos at the workstation to authenticate the user. This is why (for you) SPNEGO with Kerberos/GSSAPI is more appropriate.

If I have missunderstood your reference to TLS, please accept my appology. I was just trying to explain that you cannto simply use TLS instead of SPNEGO without changing the way your users authenticate.

Thanks,

Tim

[Former Member]

got information myself