Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Implementing SSO on CRM BSP applications

Former Member
0 Kudos

Hi,

We implemented helpdesk system, running on SAP CRM 6.0. As you can figure out that the users are working with standard BSP applications. From a long time users are complaining about authentication screens on BSP applications. Since solve the problem we decided to implement SSO solution, on SAP CRM system with Kerberos5 SNC interface. SAP CRM system is attached to a domain controller, but helpdesk users are authenticating in one another domain controller which means that SAP system and helpdesk users are working in different domains. So, we need to use cross domain solutions. The question is what way shall we follow, in order to implement SSO to CRM BSP applications? Is it same implementation with SAPGUI SSO? Anyone has a suggestion?

PS: We don't want to use SAP Portal or intermediate server, in order fill up the cookie.

20 REPLIES 20

tim_alsop
Active Contributor
0 Kudos

Orkun,

The use of Kerberos with multiple domains is certainly possible and I know of customers who are doing this. It is possible both when using SNC (e.g. with SAP GUI) or when using a Web browser (e.g. when accessing a BSP application).

Is your cross domain requirement specific to BSP / Web access, or do you also need help with SNC / SAP GUI ?

I assume you are using BSP applications with default forms based authentication, and you don't have a Java stack installed on same host or on another host in your landscape. is this correct ?

Thanks,

Tim

Former Member
0 Kudos

Hi Tim,

You are correct. Even though we installed java stack into central instance, do not need to use it while using on helpdesk system. My cross domain requirement is specific to BSP applications and we don't need to use SAPGUI SSO solution.

Thank you

tim_alsop
Active Contributor
0 Kudos

Orkun,

ok. The only way to change the authentication method for Web access to ABAP stack (where BSP apps run) is to redirect to the Java stack where you can use JAAS auth stacks to authenticate the user. For SSO with Active Directory, Kerberos and SPNEGO protocols are often used, and this will require a Java stack (not necessarily running the SAP Portal) to be available to authenticate the user. After the user has been authenticated, the JAAS auth stack will be configured to create an SSO2 ticket which will then be recognised by ABAP stack to know who the user is.

I am not aware of any cross domain issues when using Kerberos with login modules on Java stack. The domain trust is automatic since this is handled by the browser/client and the KDC (e.g. Active Directory domain controller) though the domain trust. Perhaps you don't have any domain trust ?

Thanks,

Tim

Former Member
0 Kudos

Hi Tim,

Thank you for your feedback. Firstly, helpdesk users are autheticated on active directory. So, how can I redirect the request from java stack to abap stack including "sap_username" in http header? Secondly, I can make domain trust between two domains. Would you explain how can I achieve this?

Thank you

tim_alsop
Active Contributor
0 Kudos

This message was moderated.

Former Member
0 Kudos

Hi Tim,

I checked Trustbroker product. How can we implement this solution? Shall we choose "Integrated Windows Authentication" or Java stack?

tim_alsop
Active Contributor
0 Kudos

Orkun,

The products on EcoHub are all from SAP partners and so you need to contact that partner to get help with implementation and find out the license costs.

It is not a case of whether to use IWA or Java stack. You need to make Java stack so that it supports IWA authentication of users, and this is exactly what the TrustBroker product will help you with, as well as helping you with the cross domain and redirection issue which you have described.

Thanks,

Tim

Former Member
0 Kudos

Hi Orkun,

if I understand your requirements correctly you want to enable Single Sign-On (SSO) for your users in a multi-domain environment - specifically for a BSP (ABAP) based application (SAP CRM). But you don't want to setup a seperate J2EE engine to do the authentication. There is an SAP Partner product that can do that. It supports ABAP (RFC and Web) and J2EE and whatever authentication method you may want including Active Directory (multi-domain), LDAP, SAP UME, RADIUS, Smart Cards.

Link: [SECUDE Secure Login|http://usa.secude.com/sap]. It's also a SAP Partner Product and thus certified and Powered by NetWeaver.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

Just to put things right:

The NWAS ABAP supports X.509 client certificates as standard-based SSO solution for web-based services / applications (such as BSP, WebDynpro ABAP or services provided by the built-in ITS). In addition, the NWAS ABAP is capable of evaluating SAP Logon Tickets (proprietary SSO mechanism) which an SAP Enterprise Portal or an NWAS Java system (or another NWAS ABAP system) has created - provided, that a trust relationship has been established.

The NWAS ABAP does not support SPNEGO (i.e. Kerberos authentication for web-based services), natively. As Tim has stated correctly, you'd have to use an NWAS Java which provides Kerberos authentication (as part of the standard, w/o any third-party product) and which could create a SAP Logon Ticket which then could be evaluated by the NWAS ABAP - if certain constraints (regarding user-mapping / reference system, DNS domains, trust relationship) are fulfilled.

For the (proprietary) protocols RFC and DIAG (used by SAPGUI) the situation is different: here, SNC could be used to utilize (third-party) SSO solutions, based on GSS-API. For pure Windows environments (i.e. when the ABAP server is also operated on the Windows platform) you can use the SNC wrapper libraries provided by SAP - one for MS-Kerberos, and the other one for NTLM.

In the future, SAML 2.0 will be another option (for web-based applications). But I assume that this is not of much help, right now ... (same as it will not help to know about what authentication schemes are available for WebServices (WS-Security)).

0 Kudos

perfectly explained

SECUDE Secure Login uses X.509 client certificates, which are dynamically generated (no PKI or CA required) based on any of the supported user authentication methods including AD/Kerberos.

br

Michael

0 Kudos

>

> perfectly explained

>

Well, take a kind look at [my business card|https://forums.sdn.sap.com/profile.jspa?userID=167] and you'll understand why ...

0 Kudos

no need, I know who you are

0 Kudos

>

> Just to put things right:

>

> The NWAS ABAP supports X.509 client certificates as standard-based SSO solution for web-based services / applications (such as BSP, WebDynpro ABAP or services provided by the built-in ITS). In addition, the NWAS ABAP is capable of evaluating SAP Logon Tickets (proprietary SSO mechanism) which an SAP Enterprise Portal or an NWAS Java system (or another NWAS ABAP system) has created - provided, that a trust relationship has been established.

>

> The NWAS ABAP does not support SPNEGO (i.e. Kerberos authentication for web-based services), natively. As Tim has stated correctly, you'd have to use an NWAS Java which provides Kerberos authentication (as part of the standard, w/o any third-party product) and which could create a SAP Logon Ticket which then could be evaluated by the NWAS ABAP - if certain constraints (regarding user-mapping / reference system, DNS domains, trust relationship) are fulfilled.

>

> For the (proprietary) protocols RFC and DIAG (used by SAPGUI) the situation is different: here, SNC could be used to utilize (third-party) SSO solutions, based on GSS-API. For pure Windows environments (i.e. when the ABAP server is also operated on the Windows platform) you can use the SNC wrapper libraries provided by SAP - one for MS-Kerberos, and the other one for NTLM.

>

> In the future, SAML 2.0 will be another option (for web-based applications). But I assume that this is not of much help, right now ... (same as it will not help to know about what authentication schemes are available for WebServices (WS-Security)).

Hi Wolfgang,

Regarding your words, I would like to ask some questions;

  • Spnego supports dual stack installation? I just wondering this, because Java stack is not accept LDAP configuration on configtool unless I remove "dataSourceConfiguration_abap.xml" on "com.sap.security.core.ume.service". If I remove the file on configtool java stack is not start even I created j2ee_admin and j2ee_guest users and their groups on AD.

  • Let's assume that I redirected ABAP request to Java stack for authentication purposes. As a second step, how can I redirect request from java stack to abap stack, after a succesful authentication?

Thank you for your helps,

Orkun Gedik

0 Kudos

Orkun,

It is my understanding that the SAP supplied SPNEGO login module does not support dual stack installations, which is why you are unable to make it work. Instead, you need to consider a third-party solution which also uses SPNEGO standard and works with any UME data source.

Thanks,

Tim

0 Kudos

Hi Tim,

You mean that SAP supplied SPNEGO login module forcing us to use LDAP as UME data source and cannot be applied for dual stack installation? So what about Trustbroker?

0 Kudos

>

> Hi Tim,

>

> You mean that SAP supplied SPNEGO login module forcing us to use LDAP as UME data source and cannot be applied for dual stack installation? So what about Trustbroker?

You guessed correctly. The TrustBroker Adapter product does not have this restriction. It does not use LDAP (only uses Kerberos protocol) and does not require any changes made to UME data source configuration. You can use LDAP as well if you like, but it is not required to implement SPNEGO authentication.

0 Kudos

>

> >

> > Hi Tim,

> >

> > You mean that SAP supplied SPNEGO login module forcing us to use LDAP as UME data source and cannot be applied for dual stack installation? So what about Trustbroker?

>

> You guessed correctly. The TrustBroker Adapter product does not have this restriction. It does not use LDAP (only uses Kerberos protocol) and does not require any changes made to UME data source configuration. You can use LDAP as well if you like, but it is not required to implement SPNEGO authentication.

Ok. ABAP stack has no configurable login module stack like JAAS. So as far as I guess, your product is redirecting URL to Java stack as URL parameter. At the end of the respective authentication, JAAS login module which you developed, redirects the request to ABAP stack again. Under this circumstance do we need to import some packages or make a configuration change on ICF (Abap stack)?

0 Kudos

>

> Ok. ABAP stack has no configurable login module stack like JAAS. So as far as I guess, your product is redirecting URL to Java stack as URL parameter. At the end of the respective authentication, JAAS login module which you developed, redirects the request to ABAP stack again. Under this circumstance do we need to import some packages or make a configuration change on ICF (Abap stack)?

This is correct. There are no packages or transports to install on ABAP stack, and only change on ABAP stack is to run SICF transaction and change the Redirect URL parameter. All other changes are made on Java stack when configuring our software.

0 Kudos

Tim,

How can we have its demo version?

0 Kudos

Orkun,

Please check my business card for my contact details. I cannot arrange an evaluation via SDN.

Thanks,

Tim