Use Windows Account to logon to WAS (ICM) ...

[Former Member]

Hi All !

is it possible to use a windows Domain Account to logon to WAS Applications ( BSP or Webdypro in ICM ) ?

possible with Kerberos or Certificates ?

How to implement ?

need help !

Thanks

Oliver

[WolfgangJanzen]

Short answer:

- <b>X.509</b> Client Certificates: <b>yes</b>, of course

- <b>SPNEGO</b> (aka "Windows Integrated Authentication", Kerberos-based): <b>no</b> (not "built-in")

Regarding "SPNEGO and ABAP" you'll find many SDN postings in this forum. There are some workarounds (based on http redirects) which require the usage of either an NW Java or an external ITS. If you search for those keywords (see above) you'll find those postings.

Cheers, Wolfgang

[tim_alsop]

Short answer:

- X.509 Client Certificates: no, unless the user logs onto Active Directory using x.509 certificates via PKINIT protocol, and therefore is using their certificate to determine the account name that Windows uses, and the same x.509 -> account name mapping is used within SAP to determine the SAP user name.

- Kerberos: yes, this is best approach, and easy to implement if you use the correct products/technology/tools. You have the option of displaying a login screen in browser and allowing the user to enter a valid Active Directory account name and password, or using Integrated Windows Authentication, where the credentials already issued by Active Directory when the user logged onto Windows workstation can be used to authenticate the user to SAP.

Cheers, Tim

[WolfgangJanzen]

Hopefully, Oliver is not confused, now.

X.509 client certificates are a standards-compliant SSO solution while SPNEGO was originated from Microsoft (and only later was published as IETF RFC and then was adopted also by other vendors).

Newer versions of the Microsoft Operating System prefer (the Microsoft implementation of) Kerberos. The MS ADS also provides some PKI functionality (for X.509 client certificates) - but that's indeed not their preferred approach.

But again: ABAP systems do not support SPNEGO - but X.509 client certificate based authentication.

Cheers, Wolfgang

[tim_alsop]

Wolfgang,

Yes, I hope that Oliver finds this chat/info useful, and not too confusing.

I am sorry, but the question asked in this post was related to using the Windows Account to logon to WAS. For me that means something like :

1. The user is currently logging onto Windows using an account, and is authenticating with Active Directory using this account. e.g. via password or smart card, two-factor token etc.

2. The user wants to use this same Windows account to logon to WAS ABAP. This implies the same authentication method used to logon to Windows (e.g. password, smart card, two-factor token etc.) should be used to logon to SAP WAS. This relates to the question being asked by Oliver.

So, if we first consider x.509. How are you proposing that the user authenticates using their certificate, and determines their Windows account from this certificate when they log onto SAP ? The Active Directory approach is to use PKINIT (a Kerberos pre authentication mechanism) to determine the Windows account name from the certificate based authentication, so SAP WAS would have to use PKINIT and/or share the same certificate that Active Directory uses for this to be possible. I am not aware of a method of making this work with SAP software, and if it is possible, it certainly would not be easy. Also, I am not convinced this gives Oliver what he is asking for. The only method I am aware of is to use client certificates to authenticate to SAP, and these certificates would normally be issued by SAP or via an external CA which is trusted by SAP. When using this method to logon to SAP there is no way to relate the certificate to the account name the user is aware of in Windows since the certificate authentication used by SAP is completely separate from the Windows account authentication. Hence, I would say that x.509 cannot be used to meet Olivers requirements.

Regarding SPNEGO. There was no question asked about SPNEGO - you introduced this technical term in your response, and I answered the question referring to Kerberos since this is what Oliver asked about. Also, this is not supposed to be a discussion about standards, it is a discussion about the methods available to logon to SAP WAS using a Windows account. This is the question I have answered.

I didn't say that the ABAP systems supported SPNEGO. I simply explained how it is possible to use Kerberos to authenticate to ABAP apps, either via Integrated Windows Authentication or via a logon screen that asks for Active Directory account name and password. This answers the question from Oliver clearly and without confusing him with technology - basically, what he wants to do is possible, very easy and quite commonly implemented by SAP customers, so surely these things are more important than introducing technology and standards in to the discussion when they are not relavent, and certainly better than giving the impression that x.509 is the way to go !

I don't want this post/discussion to be taken the wrong way. I wanted to make sure that Oliver gets the answer he asked for, and when you responded implying that x.509 was the best option and Kerberos was not possible I felt I had to correct you on this, in the context of the question being asked and my knowledge of the solutions available on the market to address the requirements that Oliver has asked about.

Regards,

Tim

[Former Member]

Hi Tim, Hi Wolfgang,

in summary this means ...

X509 Certificates only if the user already uses X509 Certificates to authenticate to MS AD ... Kerberos is possible with the right tools;

the authentication should take place like Tim repeated in his answer ...

"1. The user is currently logging onto Windows using an account, and is authenticating with Active Directory using this account. ==> via password

2. The user wants to use this same Windows account to logon to WAS ABAP. This implies the same authentication method used to logon to Windows (e.g. password ) should be used to logon to SAP WAS...."

@Tim

what do I need to implement Kerberos ?

Thanks

Oliver

[tim_alsop]

> @Tim

> what do I need to implement Kerberos ?

Oliver,

Here are the options available to you :

1. You can setup SAP WAS so that the credentials from the workstation are used to authenticate the user to the application without them seeing a signon screen. If the user did not log onto a Windows domain account on their workstation you can configure SAP WAS to display a signon screen in browser, asking for an Active Directory account name and password. This is commonly referred to as SSO, since the user normally only has to authenticate once when the logon to their workstation.

2. You can setup SAP WAS so that the user is always presented with a signon screen in browser, and they need to enter a valid Active Directory domain account name and password before they are allowed to logon.

In both of above cases the Active Directory account name determined after authentication has completed is mapped onto a valid SAP user for the logon to complete.

Which products ?

1. If you require option 2, or are interested in the fallback to login screen mentioned in option 1 then you need to consider the product from CyberSafe (the company I work for), called TrustBroker Adapter. This product is a SAP certified product that is designed to do what you require. I can arrange a demo or evaluation if you are interested - just contact me offline using email address from my business card. The products use a fully Active Directory compatibility implementation of Kerberos.

2. if you are only interested in option 1, and do not want to have a fallback to a login screen where user can enter an Active DIrectory account name and password, then you might want to consider the SAP SPNEGO login module, and use this with the Kerberos support built into Java. Please be aware that the Kerberos support in Java is unlikely to be 100% compatible with Active Directory expectations, e.g. you cannot use RC4 (default enc. type for Active Directory), and you cannot use canonical flag for accound name case sensitivity etc.

I hope this helps.

Regards,

Tim

[Former Member]

Hi Tim,

there's not JAVA-Stack installed for the login-modules !!!

only ABAP ... and I only want to use the BSP and WebDynpro Applications on ABAP Stack ... like cProject Suite 4;

I have to connect to http://<fqdn>:<port>/sap/.

I need a solution for this situation; with SAPGUI I can use SNC but via Browser ???

Thanks

Oliver

[tim_alsop]

Oliver,

Sorry, but you need a java stack to use this functionality. The app in SICF will be configured to redirect to a servlet on java engine, which authenticates using the login module, and then an sso2 ticket is issued, and redirect back to the app on abap engine. From that point onwards the abap engine is able to accept the sso2 ticket which was issued as a result of the login module being able to authenticate the user.

I have helped many customer with our product, and many of them are surprised that they need the java stack for this, but I am afraid there is no other option. You will need to install java stack on the same system, or on another system (not best solution, but workable).

Thanks,

Tim

[WolfgangJanzen]

Well, that confirms my initial statement (see above).

[tim_alsop]

Oliver,

If you want to logon via a Web browser to BSP applications and use Active Directory authentication (e.g. Kebreros), then you MUST install a login module (e.g. one which uses the SPNEGO protocol) in the JAVA stack, and use redirection so that the user is redirected to the BSP app in the ABAP engine after an SSO2 ticket has been issued in the Java stack. This is because the BSP app runs in the ABAP engine and the ABAP engine has no capability for adding additional authentication modules, so you can only use Basic Auth method with BSP apps unless you configure a login module stack in the Java engine and use redirection.

In this thread there are many technologies discussed, and I think it might be confusing. It should not be confusing or complex, because to do what you are requesting, only needs a Java stack that is in your landscape and a login module which supports SPNEGO / Integrated Windows Authentication. This will then complement the use of SNC for SAP GUI.

I don't see any need to involve any x.509 certificates unless you already use x.509 for client authentication in your company. It is better to use SPNEGO and use the support for this protocol already included in common browsers such as IE and Firefox.

Thanks,

Tim

[WolfgangJanzen]

Well, there is a third way:

1. User logs onto the NWAS Java using SPNEGO

2. NWAS Java is configured to act as RA (Registration Authority) requesting a X.509 client certificate to be issued for the user (which has been authenticated in step 1). SAP provides such a service, called ["SAP Passports"|http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000411810&_SCENARIO=01100035870000000202&].

3. User then has a X.509 client certificate which he can use to logon to NWAS ABAP (or any other server supporting X.509 client certificates for authentication)

Notice: step 2 will be performed only once (per user).

After that, you might also use X.509 client certificates to logon to NWAS Java.

Best regards, Wolfgang (SDN user # [167|https://forums.sdn.sap.com/profile.jspa?userID=167])

PS: with NetWeaver 7.10 Enhancement Pack 1 a new feature will be provided: rule-based certificate mapping. Instead of maintaining a single mapping entry for each user / certificate you'll then only have to define a single mapping rule for each CA (and maybe a few rule exceptions, for irregular mappings).

[tim_alsop]

Wolfgang,

This sounds like a nice feature. We already provide a mapping facility in our TrustBroker Adapter product so that the Kerberos principal name of the user at the workstation can be mapped onto a SAP user and client before an SSO2 ticket is issued. There is no x.509 involved in this, just Kerberos protocol. It means that if a user logs on via SAP GUI using Kerberos/SNC and their Kerberos principal name is mapped onto a specific SAP user and client, then the same mapping rule (in USRACL table) can be used for Browser access using our product mapping functionality. Of course, if the customer is not interested in SAP GUI as well as browser access then this functionality might not be so useful.

Thanks,

Tim

[WolfgangJanzen]

Hi Tim,

just to avoid misunderstanding: this new feature is dedicated to X.509 client certificates (which will then no longer use the ABAP table USREXTID).

For SNC mappings no such rule-based approach is planned.

But, of course, you can still use ABAP transaction SNC1 to generate those (persisted) SNC mapping entries as long as they are rule-based (static prefix + suffix, dynamic part = UserID). Remember: [we have talked about that|; some time ago.

Cheers, Wolfgang

PS: Happy New Year

[Former Member]

Just for completeness, because there are some misleading statements above: it is possible to use X.509 certificates to implement secure single sign-on to SAP (via SNC/SSL, across a large number of SAP landscape components), yet still leverage standard user authentication against Active Directory (Kerberos, Windows logon / password). This can have many advantages over a full Kerberos solution.

Peter