Single Sign-on between ABAP systems

[Former Member]

Hi experts,

I was able to config SSO between ERP 6.0 and CRM7.0 (Windows & SQL environment). In short, my SSO is working correctly. Now, I want to use different dns in the URL so that users don't know the name of the server. For example, this CRM WebUI is working correctly (http://hostname.domain.com:8000/sap/bc/bsp/sap/crm_ui_start/default.htm). I want to change to http://crmportal.whatever.net:8000/sap/bc/bsp/sap/crm_ui_start/default.htm. I want to change from "hostname.domain.com" to "crmportal.whatever.net". The new dns name (crmportal.whatever.net) is not a network domain but an internal dns entry. Because of the change, it prompt me for username and password.

My SSO configuration is very basic. I did the import/export of two ABAP systems (both systems are ABAP only) certificate in tcode strustsso2. Here is what I have done and still not work 1)change icm/host_name_full parameter to crmportal.whatever.net 2) both systems are trusted to one another

Any comments are greatly appreciated!!!

Thanks,

Allen

[Former Member]

SSO2 tickets are digitally signed by the system.

The CRM system needs to be able to verify the signature to prevent the ticket from having been changed...

With the new DNS name signing the digi-sig, the accepting system probably cannot verify it anymore.

You can trace the logon with SM20n and ST11.

If my guess is correct, the solution will be to create a new PSE for the DNS - depending on how you manage your PSEs.

You need to provide more infos...

Cheers,

Julius

[Former Member]

Hi Julius,

my PSE on both ERP and CRM is the SAP default (CN=<host_name>, OU=I<installation_number>-<company_name>, OU=SAP Web AS, O=SAP Trust Community, C=DE). If I want to create a new PSE with the new dns what would you recommend.

I did this CN=crmportal.whatever.net, OU=I<installation_number>-<company_name>, OU=SAP Web AS, O=SAP Trust Community, C=DE but it still doesn't work.

Thanks in advance,

Allen

[Former Member]

Create it as a shared PSE for the domain and import it in STRUST on the servers.

Is it possible that yopur calls to CRM are via web dispatcher between the ERP and CRM system? Does the web dispatcher terminate the SSL session?

Cheers,

Julius

[Former Member]

do you have this new URL entry in table RSPOR_T_PORTAL of the ABAP system?

Edited by: Venkat Battula on Jun 18, 2011 12:00 AM

Edited by: Venkat Battula on Jun 18, 2011 12:02 AM

[Former Member]

Sorry the one I mentioned is from portal to ABAP. I think you need to configure the new URL in SICF

[WolfgangJanzen]

SAP Logon Ticket are transmitted via cookies, thus it is required that all participating servers reside in the same DNS (sub-)domain.

SAML 2.0 does not impose this requirement; systems can reside in (totally) different domains.

ABAP systems do support SAML 2.0 (as Service Provider) as of release 7.02 (SAP_BASIS).

Cheers, Wolfgang

[tim_alsop]

Allen,

This is not an issue with cookie domains (as response from Wolfgang seems to suggest), but it is because the SPNEGO login module you are using requires a different principal name to be used since you have changed the host name used by user in browser. The browser uses the host name to request a Kerberos ticket, so if you change the hostname you need to change the principal name used for authentication.

Thanks,

Tim

[WolfgangJanzen]

Hi Tim,

where is it mentioned that Kerberos / SPNEGO is used?

I was mentioning SAP Logon Tickets because that's the most common SSO solution (up to now) being used with ABAP systems accessed via web browsers. And SAML 2.0 will be the successor - with less functional restrictions and full vendor-independent interoperability. In contrast to Kerberos SAML also works across entity realms; it's designed for the internet.

Greeting from Turkey (vacation),

Wolfgang

[tim_alsop]

Wolfgang,

I hope you are having a nice time in Turkey. I bet ti is very hot ?

Anyway, a few points:

1. SAP logon tickets are a way to recognise that a user has already authenticated for a particular domain, and the authentication of the user can be using Kerberos, certificate, basic auth etc. I feel it is wrong to compare SAML with Kerberos, since Kerberos can be used to authenticate a user and after they are authenticated a SAML token can be issued, and also a user can be authenticated using Kerberos and afterwards an SSO2 ticket can be issued. e.g. Kerberos and SAML are complementary, and not competitive as you have suggested in your response. It is like comparing Apples with Oranges

2. I assumed IWA auth is being used, because it is common for a customer to have this problem described in this thread where the user logs onto to SAP and if they use the wrong hostname in browser, the browser cannot get the HTTP/<hostname> ticket from AD - instead, it sends an NTLM token which is not accepted and therefore a login form is shown - this is what Allen mentioned in his original post, so I made a logical guess that this is why the auth is not working after host name change. Again, since the issue is about authentication of the user and the fact that a login form is shown instead of the user being authenticated, this has nothing to do with SSO2/SAML so I don't know why you introduce these into the discussion.

3. Yes, SAML is standards based and I am very familiar with this - I was even member of OASIS TC when SAML 2 was being designed and fully understand the benefits, but it is not related to this thread so I don't see nay need to discuss the benefits of using SAML instead of SSO2 (SAP proprietary) tokens.

Thanks,

Tim

[Former Member]

Hi experts,

Great discussion however after reading discussion I am still digging for a solution.

@Julius I tried different combination with new PSE but don't see to work. For example,

CN=crmportal.whatever.net, OU=I<installation_number>-<company_name>, OU=SAP Web AS, O=SAP Trust Community, C=DE

@Tim This SSO is between two ABAP systems. Nothing related to Windows environment. Just good old transaction strustoss2 and import/export certificate between systems.

Again, this is a dns entry (nothing related to domain stuff) so users don't know server name.

Should I be looking into implementing Kerberos? Any links or docs is greatly appreciated.

Thanks,

Allen

[Former Member]

well, i am not an expert, but recently i did hardware migration where we used internal dns and its working fine.

you URL is perfect.. its taking you to login screen.?

xyz.wahever.com > will redirect to wgate services, will run scripts. and start services..

before that it will ask for id and password. in sso it will take. if you get login screen . seems its not authenticating tickets.

1) if you have tried what Julius has suggested, please let me know (was it working with full Url what u had earlier).

2)please check in SAP table if you have entry for you new name. i belive you are using integrated ITS?

Thanks,

PKP

[Former Member]

Hi Allen,

If you are really speaking only about SSO between 2 abap systems (so not IWA), the PSE used is the System PSE and not the SSL server PSE.

So there should be no need to change the certificate content because it has nothing to do with the DNS name but only with the SID :

CN=SID, OU=I<installation_number>-<company_name>, OU=SAP Web AS, O=SAP Trust Community, C=DE

If you changed the DNS domain of one only of the abap system, and you want SSO with a web browser (not sapgui) yes, you might have a problem that the saplogon cookie is not sent to the second abap system because the cookie is not valid for the second domain.

With a SAP portal as the ticket issuing sytem, the classic solution is domain relaxing if the last part of the 2 domains is the same.

Between 2 abap systems, one possible workaround is to install a SAP web dispatcher for the second abap system in the same DNS domain as the first abap system

Regards,

Olivier.

[Former Member]

Hello,

we have used directorty Authentication filter, with webdispatcher .

Our network team had wokrd for directory authentication filter since we were using two webservers for load balancing.

Thanmks,

Prasant K paichha

[Former Member]

Hello,

Sorry, but I don't understand what you are speaking about. Is your post in the intended thread ?

Regards,

Olivier

[Former Member]

Just guessing here... but I interpreted the series of words to be that the http request goes to the webdispatcher which then load balances the request to a server in the domain. The http response from that server uses a network address translator as forward proxy which overwrites the URL presented back to the user to hide the host name - making it look like a different domain name (for the end users...).

However I cannot see how this would work if the network domains are different with SSO2 cookies used for authentication and the user tried to click on something to send another request to the server, so suspect that it is only a masking of the hostname which is being refered to here.

A wild guess...

Cheers,

Julius

[Former Member]

Hi everyone,

Thank you for your input. Very much appreciated. I finally figure how to resolve this issue. It take me 3 days of search and finally it come to me. It's a simple solution (I feel so dump for not thinking this the first place). Solution is to create a new dns entry for ERP with the same domain as CRM. Then, goes into CRM under tcode crms_ic_cross_sys and then modify the url accordingly. This is the setting where CRM call the backend system which is ERP.

Thanks again,

Allen