SSO between R/3 and Web Server Filter is not worki...

Former Member · ‎11-29-2007

Hi all,

I have to configure SSO to access from SAP R/3 to a third-party web application through Web Server Filter.

R/3  WSF  3rdParty App

I think everything is configured properly, but when I issue the http request from R/3 to WSF I get the following error in sapsso.log file in apache server:

======================================================

-

trc file: "/usr/local/app/apache/sapsso.log", trc level: 3, release: "620"

-

Thu Nov 29 13:44:40 2007

Webserver Ticket Filter Release Version 5.0.2.8

Loading of the props returned 0=OK.

Max cache size = 0

Initialization done.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

======================================================

And in the error_log file of the apache http server there’s the following:

======================================================

proxy_cache.c(969): No CacheRoot, so no caching. Declining.

proxy_http.c(586): Content-Type: (null)

Ticket is AjQxMDIBABgAUgBBAEwATABVAEUAIA...

Got date from ticket.

Cur time = 200711291244.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196426640, CreTime_t = -496601312

validity: 216000, difference: 1693027952.000.

proxy_cache.c(969): No CacheRoot, so no caching. Declining.

proxy_http.c(586): Content-Type: (null)

Ticket is AjQxMDIBABgAUgBBAEwATABVAEUAIA...

Got date from ticket.

Cur time = 200711291244.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196426640, CreTime_t = -496601312

validity: 216000, difference: 1693027952.000.

proxy_cache.c(969): No CacheRoot, so no caching. Declining.

proxy_http.c(586): Content-Type: (null)

Ticket is AjQxMDIBABgAUgBBAEwATABVAEUAIA...

Got date from ticket.

Cur time = 200711291244.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196426640, CreTime_t = -496601312

validity: 216000, difference: 1693027952.000.

proxy_cache.c(969): No CacheRoot, so no caching. Declining.

proxy_http.c(586): Content-Type: (null)

======================================================

It seems like there isn’t the date in the ticket issued by SAP R/3. However, I tried to configure sso between the same R/3 server and an EP and worked fine.

I also tried to decrypt the ticket issued by R/3 but I get a segmentation fault.

Does anyone can help me?

Thanks in advance.

Roger Allué i Vall

WolfgangJanzen · ‎11-29-2007

Can you please tell us what you actually intend to achieve?

As you have a WebAS ABAP system (6.40?) which is able to act as http(s) client one question is: why do you use the Web Server Filter to access the 3rd Party Application (indirectly) - why not accessing the application straight ?

Which kind of authentication is expected / demanded by the 3rd Party Application? What kind of application framework is hosting that application?

Important question: which component acts as http client - the browser or the WebAS ABAP?

Former Member · ‎11-29-2007

Ok, the R/3 is acting as a client. We are using the GUI HTML Container. The reason of using web server filter as middleware is to ensure single sign-on with 3rd Party applications that do not support it. This applications support http header authentication, so we use WSF as the access point, just to redirect the requests for clients that are authenticated via SSO.

Our customer wants to access these applications from EP and also within sap r/3. When we configure the SSO connection between EP --> WSF --> 3rd Party App, it works fine. To check if the problem was that R/3 generated a bad ticket we tried to configure SSO between R/3 and EP. And It worked fine. However, when we try to configure SSO connection between R/3 --> WSF --> 3rd Party App we get the error above. And that's the functionality we need.

Thanks for your response.

WolfgangJanzen · ‎11-29-2007

Hold on - there is an inconsistency in your statement:

"Ok, the R/3 is acting as a client. We are using the GUI HTML Container."

If you are using the SAPGUI HTML Control (and the mechanism described in <a href="https://service.sap.com/sap/support/notes/612670">SAP Note 612670</a>) then the http client is the browser (= HTML control, based on IExplorer) - and not the ABAP backend.

I think it would help a lot if you could analyse the http request which is received by the 3rd Party Application (respectively the Web Server Filter / the Apache server) - at least the http header part. I would like the see the entire content of the cookie MYSAPSSO2.

You wrote:

The reason of using web server filter as middleware is to ensure single sign-on with 3rd Party applications that do not support it.

I understand, now.

Former Member · ‎11-29-2007

Yes you are right. I wanted to say that the HTTP request is initiated from R/3 (Sid RHI), but with the GUI Html control.

I executed SSO2 transaction in the R/3 system RHI against itself:

Issuing System for the Logon Ticket

SAP System RHI Client 100

Certificate of the Issuing System for the Logon Ticket

Owner CN=RHI

Issuer CN=RHI

Serial Number 00

Validity 20071127 190707 20380101 000001

Check Sum E4:CA:63:0A:32:1D:EC:63:3D:75:60:04:42:66:76:57

Profile Parameters login/create_sso2_ticket = 2

System RHI Is Creating Logon Tickets That Do not Include Its Certificate

The Current System RHI Is Also the Issuing System for the Logon Ticket

An Entry in Certificate List of RHI Is not Necessary

The Certificate for System RHI Is Included In the Certificate List for System RHI

System RHI Accepts Verified Logon Tickets for System RHI

-

Own System Data

SAP System RHI Client 100

Profile Parameters login/accept_sso2_ticket = 1

Logon Tickets Are Accepted

Certificate List

The Certificate List Is Used To Verify the Digital Signature for the Logon Ticket

/usr/sap/RHI/DVEBMGS02/sec/SAPSYS.pse

Owner CN=RHI

Issuer CN=RHI

Serial Number 00

This Is the Certificate of the Issuing System for Logon Tickets

Owner CN=PHI

Issuer CN=PHI

Serial Number 13D565A8

Systems for Which RHI Accepts Verified Logon Tickets

The Access Control List Defines Which Systems the Verified Logon Tickets Are Accepted From

Table TWPSSO2ACL

SAP System PHI Client 000

Owner CN=PHI

Issuer CN=PHI

Serial Number 13D565A8

-

Application server PSE:

ID: CN=RHI

Namespace:

Profiles: /usr/sap/RHI/DVEBMGS02/sec/SAPSYS.pse

OK: file available, length: 1.911

OK: local PSE identical to original in database

OK: security toolkit available

Version

SSFLIB Version 1.555.21 ; SECUDE(tm) SAPCRYPTOLIB - SNC for SAP Server components and SSL - Version 5.5.5C (c) SECUDE GmbH 1990-2004

OK: signature tested successfully

It seems everything is configured properly (instance parameters, pse, etc.).

Any idea?

Thanks in advance.

Roger Allué i Vall.

Former Member · ‎11-29-2007

Can you tell me how to get the cookie MYSAPSSO2? How can I give it to you?

Former Member · ‎11-29-2007

Here's a excerpt of a strace of the httpd processes when receive the http request:

13863 accept(16, <unfinished ...>

13864 accept(16, <unfinished ...>

13865 accept(16, <unfinished ...>

13866 accept(16, <unfinished ...>

13867 accept(16, <unfinished ...>

13868 accept(16, <unfinished ...>

13872 accept(16, <unfinished ...>

13863 <... accept resumed> {sa_family=AF_INET, sin_port=htons(2476), sin_addr=inet_addr("10.80.183.46")}, [16]) = 3

13863 rt_sigaction(SIGUSR1, , {0x805fd50, [], SA_INTERRUPT}, 😎 = 0 13863 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 13863 getsockname(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.41.235.48")}, [16]) = 0 13863 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 13863 read(3, "GET /Silicon/loginPasarela.jsp?accion=urgencias&icu=0010000694%20&nhc=0000147810 HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /\r\nAccept-Language: ca\r\nsap-mysapsso: 200711291818281ppOT/XT2eKtb8Unh0aexQAjQxMDIBABgAUgBBAEwATABVAEUAIAAgACAAIAAgACACAAYAMQAwADADABAAUgBIAEkAIAAgACAAIAAgBAAYADIAMAAwADcAMQAxADIAOQAxADcAMQA4BQAEAAAAPAkAAgBj/wFQMIIBTAYJKoZIhvcNAQcCoIIBPTCCATkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCARgwggEUAgEBMBMwDjEMMAoGA1UEAxMDUkhJAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzExMjkxNzE4MjhaMCMGCSqGSIb3DQEJBDEWBBRNZ7rlzxjw9r4UNi4m/MBvHYXK0TANBgkqhkiG9w0BAQEFAASBgNeYexwxhY7cUDZG7mGKmaljgqt2NBdlV!WA/4FUSFVpIewDtMQDtLjcAcVRsH2QMWxPs0!QSvlqlJHdm7VIvMe9pWMvs6ld8/U!lOTSQqtNyI!am770SgRMR60eiV3Ir8q8wfR8VXnO9acHHePnVN4O24!jwCOPxm6XAQuKMUAS\r\nsap-mysapred: http://sapwhi01.argos.gencat.intranet/Silicon/loginPasarela.jsp?accion=urgencias&icu=0010000694 &nhc=0000147810\r\nAccept-Encoding: gzip, deflate\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2)\r\nC", 4096) = 1260 13863 rt_sigaction(SIGUSR1, , , 😎 = 0

13863 time(NULL) = 1196356708

13863 read(3, "ookie: MYSAPSSO2=AjQxMDIBABgAUgBBAEwATABVAEUAIAAgACAAIAAgACACAAYAMQAwADADABAAUgBIAEkAIAAgACAAIAAgBAAYADIAMAAwADcAMQAxADIAOQAxADcAMQA4BQAEAAAAPAkAAgBj%2fwFQMIIBTAYJKoZIhvcNAQcCoIIBPTCCATkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCARgwggEUAgEBMBMwDjEMMAoGA1UEAxMDUkhJAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzExMjkxNzE4MjhaMCMGCSqGSIb3DQEJBDEWBBRNZ7rlzxjw9r4UNi4m%2fMBvHYXK0TANBgkqhkiG9w0BAQEFAASBgNeYexwxhY7cUDZG7mGKmaljgqt2NBdlV%21WA%2f4FUSFVpIewDtMQDtLjcAcVRsH2QMWxPs0%21QSvlqlJHdm7VIvMe9pWMvs6ld8%2fU%21lOTSQqtNyI%21am770SgRMR60eiV3Ir8q8wfR8VXnO9acHHePnVN4O24%21jwCOPxm6XAQuKMUAS; JSESSIONID=50B5570A234B89887690DF50A993477D\r\nConnection: Keep-Alive\r\nHost: sapwhi01.argos.gencat.intranet\r\n\r\n", 4096) = 730

13863 time(NULL) = 1196356708

13863 write(2, "Thu Nov 29 18:18:28 2007\n", 25) = 25

13863 write(2, "Ticket is AjQxMDIBABgAUgBBAEwATABVAEUAIA... \n", 45) = 45

13863 time(NULL) = 1196356708

13863 write(5, "\nChecking validity...\n", 22) = 22

13863 time(NULL) = 1196356708

13863 write(2, "Got date from ticket.\n", 35) = 35

13863 time(NULL) = 1196356708

13863 write(2, "Cur time = 200711291718.\n", 25) = 25

13863 time(NULL) = 1196356708

13863 write(2, "Computing validity in hours.\n", 29) = 29

13863 time(NULL) = 1196356708

13863 write(2, "Computing validity in minutes.\n", 31) = 31

13863 time(NULL) = 1196356708

13863 write(2, "CurTime_t = 1196443080, CreTime_t = -496601312 \n", 48) = 48

13863 time(NULL) = 1196356708

13863 write(2, "validity: 216000, difference: 1693044392.000.\n", 46) = 46

13863 time(NULL) = 1196356708

13863 write(5, "Ticket Validation Error: expired.\n", 34) = 34

13863 time(NULL) = 1196356708

and so on.

WolfgangJanzen · ‎11-29-2007

Your SAP Logon Ticket (contained in the cookie MYSAPSSO2) looks o.k.:

Type: SAP Logon Ticket

Codepage: 4102

R/3 User: RALLUE

Portal User:

Issued By: RHI (100)

Issued At: 11/29/2007 5:18:00 PM

Validity: 60 Hours, 0 Minutes

Valid until: 12/2/2007 5:18:00 AM

WolfgangJanzen · ‎11-29-2007

CurTime_t = 1196443080, CreTime_t = -496601312

This looks like the cause.

In consequence a wrong timeframe is calculated:

validity: 216000, difference: 1693044392.000

Validity: 216000 (seconds = 60 hours)

Difference: 1693044392 (seconds = ca. 19595 days ...)

Which operating system are you using?

There seems to be a problem with the timestamp calculation routine.

Former Member · ‎11-29-2007

These are our systems:

R/3 System:

.root:/ > uname -a

AIX lpar1 3 5 0002D0D7D600

.root:/ > date

Thu Nov 29 19:38:21 CET 2007

.root:/ >

Web Server Filter:

sapwhi01-node:/usr/local/app/apache/conf # uname -a

Linux sapwhi01-node 2.6.16.46-0.12-bigsmp #1 SMP Thu May 17 14:00:09 UTC 2007 i686 i686 i386 GNU/Linux

sapwhi01-node:/usr/local/app/apache/conf # date

Thu Nov 29 19:38:27 CET 2007

Thank you in advance.

Roger Allué i Vall.

WolfgangJanzen · ‎11-29-2007

Thanks. Relevant is the machine where the Apache / Web Server Filter is running - not the one of the ABAP system.

I'd suggest to report this as support case to SAP - with reference to this SDN thread. It is also helpful if you report the version of the Web Server Filter (5.0.2.8

) - and whether this is a 32 / 64 bit application.

The essence is:

The UTC timestamp "11/29/2007 5:18:00 PM" is wrongly converted to "CreTime_t = -496601312". So, it's not related to unsynchronized system-clocks (but thanks for providing that information as well). Quite obviously we have a numeric overflow.

Cheers, Wolfgang

Former Member · ‎11-29-2007

Linux Kernel: 32bits

Web Server Filter: 5.0.2.8

Here's 2 excerpts from the apache error_log file:

1.- When accessing from SAP R/3 --> WSF --> 3rd Party app (NOT WORKING):

============================================================

[Thu Nov 29 20:01:15 2007] [debug] proxy_http.c(586): Content-Type: (null)

Ticket is AjQxMDIBABgARABHAEEAUgBDAEkAQQ...

Got date from ticket.

Cur time = 200711291901.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196449260, CreTime_t = -496602272

validity: 216000, difference: 1693051532.000.

[Thu Nov 29 20:01:15 2007] [debug] proxy_cache.c(969): No CacheRoot, so no caching. Declining.

[Thu Nov 29 20:01:15 2007] [debug] proxy_http.c(586): Content-Type: (null)

============================================================

2.- When accessing from EP --> WSF --> 3rd Party app (WORKING):

============================================================

Thu Nov 29 19:52:47 2007

Ticket is AjExMDAgAA5wb3J0YWw6REdBUkNJQY...

Got date 200711291844 from ticket.

Cur time = 200711291852.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196448720, CreTime_t = 1196448240

validity: 28800, difference: 480.000.

Argument Dump for ticket verification:

Content byte stream:

Signature byte stream:

Encoded content byte stream:

Verify returns 0 [ssoxxsgn.c 189]

Certificate is:

Got date 200711291844 from ticket.

Cur time = 200711291852.

Computing validity in hours.

Computing validity in minutes.

CurTime_t = 1196448720, CreTime_t = 1196448240

validity: 28800, difference: 480.000.

============================================================

Please take a look at step: "Got date from ticket." (In original log there are some blank space between "date" and "from" words) of the first excerpt. As you can notice when WSF is unable to get the date. However, when the ticket is send by EP, WSF can validate it without problem: "Got date 200711291844 from ticket.". I think this is the problem: the ticket data.

Any Idea?

Thanks in advance.

WolfgangJanzen · ‎11-29-2007

No, the ticket content is not the problem - I have been able to extract the content without any problems (using an inhouse tool). I assume that only the ticket parser of the WSF has some problems.

Recall what you wrote previously:

To check if the problem was that R/3 generated a bad ticket we tried to configure SSO between R/3 and EP. And It worked fine.

Good night - it's already past 8pm ... (German time)

Cheers, Wolfgang

WolfgangJanzen · ‎11-29-2007

Last one:

I assume you are aware of <a href="https://service.sap.com/sap/support/notes/442401">SAP Note 442401</a> (with the attached ZIP file).

Which mod_sapsso.so file did you extract from the ZIP file?

5.0.2.8\filter\bin\linux\i386\apache or

5.0.2.8\filter\bin\linux\i386\apache\EAPI ?

Former Member · ‎11-29-2007

If we try to use the EAPI one apache http server do not start:

API module structure `ModuleAccessCookie' in file /usr/local/app/apache/libexec/mod_sapsso.so is garbled - perhaps this is not an Apache module DSO?

bin/apachectl start: httpd could not be started

So we use the other one.

WolfgangJanzen · ‎11-29-2007

Sorry - I must have been blind:

Ticket is AjQxMDIBABgARABHAEEAUgBDAEkAQQ...
Got date              from ticket.
Cur time = 200711291901.
Computing validity in hours.
Computing validity in minutes.
CurTime_t = 1196449260, CreTime_t = -496602272

Well - obviously the ticket parser was unable to retrieve that information (InfoUnit 0x04) from the ticket. So, there's something wrong with the parser.

However, the ticket itself looks o.k.:


0x04 00 32 00 30 00 30 00 37 00 31 00 31 00 32 00 39   .2.0.0.7.1.1.2.9
     00 31 00 37 00 31 00 38 00 00 00 00 00 00 00 00   .1.7.1.8........

Can you please set the log_level = 3 (verify.properties file)?

Former Member · ‎11-30-2007

Yes, it is at level 3 and we just get this:

-

trc file: "/usr/local/app/apache/sapsso.log", trc level: 3, release: "620"

-

Thu Nov 29 20:31:51 2007

Webserver Ticket Filter Release Version 5.0.2.8

Loading of the props returned 0=OK.

Max cache size = 0

Initialization done.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

Checking validity...

Ticket Validation Error: expired.

WolfgangJanzen · ‎11-30-2007

Sorry, but in that case I cannot help you any further.

I did hope that tracelevel 3 would reveal more details.

Well, if I interpret <a href="https://service.sap.com/sap/support/notes/442401">SAP Note 442401</a> correctly, then the Web Server Filter approach is deprecated; you might have to switch to the SAPSSOEXT library approach.

Former Member · ‎11-30-2007

Do you think that the problem could be the encryption algorithm? Which one should we use? RSA or DSA? And what about the length? 512 or 1024?

Thank you again!

WolfgangJanzen · ‎11-30-2007

No, that's not related at all.

First, the ticket is parsed. Only afterwards, the digital signature is verified.

(Notice: the ticket is not encrypted, but digitally signed)

ABAP systems always use DSA certificates to perform the digital signature operations. For interoperability reasons Java systems should also only use DSA certificates (and no RSA certificates) when dealing with SAP Logon Tickets.

SSO between R/3 and Web Server Filter is not working