cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Single-Sign-On (SSO) configuration on JAVA Stack through HTTP Header method

Former Member
0 Likes
4,552

Hello SDN community,

in the context of a Proof of Concept, we are testing the integration of Microsoft Sharepoint Portal with SAP Backend (addin) systems.

As the architecture impose use an external scenario (access from the internet), we couldn't use the Kerberos (SPNego) solution and thus we chosed the http header solution which in short uses an intermediary web server (in this case the IIS of the MOSS solution) which will act as authority.

I miss information on how the workflow works for this http header authentication method. Through the visual administrator of the addin JAVA stack, it is possible to configure each application with a customized authentication (a choice of security modules). But this all that I know.

My task is to configure SSO. From a sharepoint portal, the user should be able to access Web Dynpros and BSPs. I imagine that the very first call to a webdynpro or bsp (or maybe when we log on the sharepoint portal), the request to the WDP or BSP will first be forwareded by the intermediary server to the JAVA stack (or is it the SAP dispatcher that has to be configured).

Is there an application to be built on the java stack to deal with the authentication, modify http header?

What will the Java stack return? a sap long ticket? a token?

How will the redirect work (to by example a BSP which is in the ABAP stack)?

SAP preconise to secure with SSL the link between the intermediary web server and the JAVA stack, is IP restriction also a solution?

A lot of questions about how this SSO http header should work,

I would be very greatful for any help, or info,

Kind regards,

Tanguy Mezzano

View Entire Topic
Former Member
0 Likes

Hi,

I have implemented this solution.

What you absolutely need is an intermediary server that adds the appropriate header to the request (I used Apache).

In your case:

Client -> Intermediary Server (ISS) adds the Request Header (e.g. REMOTE_USER: SAP J2EE

On the SAP J2EE you can use any application but since you want to redirect to an ABAP Stack or a BSP I suggest you create a custom application (All you need is a JSP that performs a redirect to a configurable resource (in your case your BSP on the ABAP Stack)

Here is a sample code for such a JSP:

<%@ page language="java" %>

<%

    String redirectURL = request.getParameter ("redirectURL");
    response.sendRedirect (redirectURL);
%>

This is all you need. You built an Enterprise Application using NWDS and deploy it to your J2EE Engine

Let's assume the application is called SSOredirect then you can call it using the following URL

http:// See the following documentation to make this work:

http://help.sap.com/saphelp_nw70/helpdata/EN/68/5ddc40132a8531e10000000a1550b0/frameset.htm

As you already noticed SAP suggests to use mutual authentication to make this more secure which means that your intermediary server uses SSL to communicate with the J2EE and performs Authentication using a client certificate (In this case you will have to use/add the ClientCertLoginModule to your logon stack and you will have to confgure some more on your J2EE in order to make this work. For the beginning you should cope with the HeaderVariableLoginModule and make it work and when it works start to make your scenario more secure.)

It's a matter of security but I guess you can use another module to achieve an additional amount of security. There is a module called IPHeaderVariableLoginModule provided by a guy called Jörg Wulftange who works for Platinion. It extends the SAP HeaderVariableLoginModule and uses an IP List to make sure that only configured Hosts are recongnized within the module. In this scenario you would add the IP of your IIS to the IP List and only this host will be recognized when performing Authentication based on the Header Variable

There is a useful document on the SDN that explains the Module and its usage:

See: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/069eaf4b-0901-0010-6e89-d1fcceeb...

You can consider using this.

Now we come to your authentication to the ABAP Stack:

When Header Variable Login works all you have to do is adding the

CreateTicketLoginModule after the IPHeaderVariableLoginModule ot HeaderVariableLoginModule in the JAAS Logon Stack of your SSOredirect Application

Your application will create a logon ticket (MYSAPSSO2 Cookie) that can be used to authenticate to your ABAP Backend (I assume you already configured your Backend to accept logon tickets and you added the J2EEs certificate to the Trust Store of your Backend using Transaction strustsso2)

That's all

Hope this helps

If you need additional help let me know (reward points for useful posts are always appreciated )

Cheers

Former Member
0 Likes

Hey Tanguy,

did my post help or do you have further questions??

Former Member
0 Likes

Hello Marcel,

yes, sorry! Your post did help me a lot, I was coming back to you. We are still doing a lot of tests, most of what you explained has been configured except the IP restriction module (we will configure this at the end to avoid any other new problems).

But I have 2 problems:

1) We have deployed a web dynpro on the Java Stack, it has its Security Provider configured with HttpHeader module. When I surf to that web dynpro (thus without adding a header), I am redirected to a BasicPassword Logon page what is normal and this works. But when I try to connect to the web dynpro url with a Java Application by adding an http header: myheader = myID I don't get anything back from the Java Stack. Maybe I am not writting correctly my Java application with http header...

2) When I deploy the redirect JSP on the Java stack, I have configured its Sercurity Provider with httpheader but it doesn't seem to take effect as when I surf on the url, I get directly to the page...

I will definitely reward you with points,

Thanks a lot for your help,

Regards,

Tanguy

Former Member
0 Likes

Hi Tanguy,

1) We have deployed a web dynpro on the Java Stack, it has its Security Provider configured with HttpHeader module. When I surf to that web dynpro (thus without adding a header), I am redirected to a BasicPassword Logon page what is normal and this works. But when I try to connect to the web dynpro url with a Java Application by adding an http header: myheader = myID I don't get anything back from the Java Stack. Maybe I am not writting correctly my Java application with http header...

Can you call any other webdynpro application using your Java Code? You should at least get some initial page and/or the 401 Return Code for Basic Authentication. Maybe you are being redirected and your Code does not follow redirects?? Try using a sniffer to sniff the communication or use Apache Jakarta Commons TCP Mon to see outgoing and incoming HTTP traffic. The tool serves as a proxy and you will configure it to connect to your backend while your JAVA Code does not create a connection to your backend but to TCPMon instead in order to see the communication!

=> see https://tcpmon.dev.java.net/

or http://ws.apache.org/commons/tcpmon/download.cgi

2) When I deploy the redirect JSP on the Java stack, I have configured its Sercurity Provider with httpheader but it doesn't seem to take effect as when I surf on the url, I get directly to the page...

make sure that you have configured the Security Constraints and the secured resources for you web application. If it does not contain any the Logon Stack is not processed and you can access your application without authentication.

You have to make changes to your web-j2ee-engine.xml and web.xml (using NWDS) in order to achieve this.

Here are very basic samples for both files:

web-j2ee-engine.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-j2ee-engine SYSTEM "web-j2ee-engine.dtd">
<web-j2ee-engine>
	<security-role-map>
		<role-name>DefaultSecurityRole</role-name>
	</security-role-map>
	<login-module-configuration/>
</web-j2ee-engine>

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
	<display-name>WEB APP</display-name>
	<description>WEB APP description</description>
	<welcome-file-list>
		<welcome-file>index.jsp</welcome-file>
	</welcome-file-list>
	<security-constraint>
		<display-name>My Test Web APP Protected Area</display-name>
		<web-resource-collection>
			<web-resource-name>WebResource</web-resource-name>
			<url-pattern>/*</url-pattern>
			<http-method>GET</http-method>
			<http-method>POST</http-method>
		</web-resource-collection>
		<auth-constraint>
			<role-name>DefaultSecurityRole</role-name>
		</auth-constraint>
	</security-constraint>
	<security-role>
		<role-name>DefaultSecurityRole</role-name>
	</security-role>
</web-app>

Hope this helps (You can reward points for every single useful answer )

Cheers

Former Member
0 Likes

Hello,

well, I really have difficulties to set up that http header authentication. But you are of great help. I've added descriptors and yes only when they are configured will the jsp authentication work.

I have configured the auth. template stack as follows:

EvaluateTicket - Sufficient

HttpHeader - Optional

CreateTicket - Optional

BasicLoginPwd - Requisite

CreateTicket - Optional

I am now trying to test the http header with a java application, I am using HttpUrlConnection class but always get 401 error msg. I'm not sure of my code. I have added in the login module stack HttpHeader - Optional the variable: Header = myVar. Thus in my java code which is making the Http request call I have the line:

conn.addRequestProperty("myVar","userID");

Is this the right why to test Http Header Authentication?

Thx for your help,

Tanguy

Former Member
0 Likes

Hi,

I've not used this class yet but if it is intended to create a connection and perform a request than it looks alright. You should have a look at your dispatcher log on J2EE to see if your header is properly set and reaches the J2EE as intended:

It is located under:

/usr/sap/<SID>/JC<XX>/j2ee/cluster/dispatcher/log/services/http

Open the latest req_resp.X.trc file (All requests, responses and headers can be logged here so you can see if your request actually contains the header you are adding in your request!)

If you cannot see anything here you have to enable logging.

In this case start Visual Admin and call the HTTP Provider Service of your Dispatcher Node. In the Properties set the Property HttpTrace to enable (I think default is disable)

Everything should be logged now (Don't do this in production environment since it has an impact on performance)

If this works we have a look at your module stack (If your app does not work let me know. I can send you a sample code using Apache Commons HTTP Client!)

I have configured the auth. template stack as follows:

EvaluateTicket - Sufficient

HttpHeader - Optional

CreateTicket - Optional

BasicLoginPwd - Requisite

CreateTicket - Optional

I guess the JAAS Flag for the first occurance of CreateTicket should be sufficient and not optional. Otherwise you will always run into BasicLogin even if HttpHeader and CreateTicket already succeeded. I think that is not what you want.

I guess that you are not sending any Basic Credentials from your java application and that is why you keep getting the 401 response (Authentication required)

Here is a helpful explanation of the JAAS Flags:

http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/login/Configuration.html

Here is an extract:

3) Sufficient   - The LoginModule is not required to
			succeed.  If it does succeed, control immediately
			returns to the application (authentication does not
			proceed down the LoginModule list).
			If it fails, authentication continues down the
			LoginModule list.

4) Optional     - The LoginModule is not required to
			succeed.  If it succeeds or fails,
			authentication still continues to proceed down the
			LoginModule list.

The best way to see which modules in the stack are processed and if authentication succeeds is to increase the loglevel (severity) of some log locations:

Increase the following locations to all using log configurator service in visual admin (this works on the fly and there is no restart necessary)

- com.sap.security.server.jaas

- com.sap.engine.services.security

After increasing the severity check your security log under /usr/sap/<SID>/JC<XX>/j2ee/cluster/serverX/log/system in order to see how the modules in your stack are processed!

Hope this helps (Please reward points if helpful

Cheers

Former Member
0 Likes

Thx for the logging, it's wonderfull , I'm getting this error:


{HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Upload Protected Area"

Do you have idea what is it related to?

Well, after updating the severity as you suggested to me, I see the server logs:


2. com.sap.security.core.server .jaas.HeaderVariableLoginModule            REQUISITE                                                Cannot load login module class.
3. com.sap.security.core.server.jaas.CreateTicketLoginModule               SUFFICIENT  ok          false      false                 
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   SUFFICIENT  ok          true       true                  
5. com.sap.security.core.server.jaas.CreateTicketLoginModule               OPTIONAL    ok                     false                 
Central Checks                                                                                true                  #
#1.5 #000C299F469E007200000000000011180004512126039C3F#1215102720380#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleImpl#J2EE_ADM_JD2#41##n/a##8fa24ac0491d11ddb9c8000c299f469e#SAPEngine_Application_Thread[impl:3]_10##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleImpl#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}].#3#ACCESS.OK#SAP-J2EE-Engine#all#
#1.5 #000C299F469E007200000001000011180004512126039D10#1215102720380#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleReference#J2EE_ADM_JD2#41##n/a##8fa24ac0491d11ddb9c8000c299f469e#SAPEngine_Application_Thread[impl:3]_10##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleReference#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}] referencing J2EE security role [{3} : {4}].#5#ACCESS.OK#service.naming#jndi_get_initial_context#SAP-J2EE-Engine#all#
#1.5 #000C299F469E00720000000200001118000451212603A50F#1215102720380#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleImpl#J2EE_ADM_JD2#41##n/a##8fa24ac0491d11ddb9c8000c299f469e#SAPEngine_Application_Thread[impl:3]_10##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleImpl#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}].#3#ACCESS.OK#SAP-J2EE-Engine#administrators#
#1.5 #000C299F469E00720000000300001118000451212603A5D0#1215102720380#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleReference#J2EE_ADM_JD2#41##n/a##8fa24ac0491d11ddb9c8000c299f469e#SAPEngine_Application_Thread[impl:3]_10##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleReference#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}] referencing J2EE security role [{3} : {4}].#5#ACCESS.OK#service.naming#jndi_all_operations#SAP-J2EE-Engine#administrators#
#1.5 #000C299F469E004E0000003200001118000451212604B4AD#1215102720442#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleReference#J2EE_ADM_JD2#41##n/a##612707d0491d11dd9c00000c299f469e#SAPEngine_Application_Thread[impl:3]_15##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleReference#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}] referencing J2EE security role [{3} : {4}].#5#ACCESS.OK#service.naming#jndi_get_initial_context#SAP-J2EE-Engine#all#
#1.5 #000C299F469E004E0000003300001118000451212604B5DD#1215102720442#/System/Security/Audit/J2EE##com.sap.engine.services.security.roles.SecurityRoleReference#J2EE_ADM_JD2#41##n/a##612707d0491d11dd9c00000c299f469e#SAPEngine_Application_Thread[impl:3]_15##0#0#Info#1#com.sap.engine.services.security.roles.SecurityRoleReference#Java###{0}: Authorization check for caller assignment to J2EE security role [{1} : {2}] referencing J2EE security role [{3} : {4}].#5#ACCESS.OK#service.naming#jndi_all_operations#SAP-J2EE-Engine#administrators#

Finally I see that we are not far from the problem, how come the http header login module cannot load?

Without you I would have never found for sure ^^

Former Member
0 Likes

Hi Tanguy,

Yes, logging is cool stuff

The 401 is the engine response code because you are running into BasicPasswordLogin again:

2. com.sap.security.core.server .jaas.HeaderVariableLoginModule            REQUISITE                                                Cannot load login module class.
3. com.sap.security.core.server.jaas.CreateTicketLoginModule               SUFFICIENT  ok          false      false
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   SUFFICIENT  ok          true       true

HeaderVariable (2) and CreateTicket (3) fail so you run into Basic (4) and the engine sends a 401 indicating that authentication is required.

{HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Upload Protected Area"

The fact that your login module cannot load appears to me as follows:

Assuming that your Post does not contain any copy and paste errors I guess you have added the HeaderVariableLogin Module manually in security Provider / UserManagement / Manage Security Stores (Was the module not listed??)

com.sap.security.core.server .jaas.HeaderVariableLoginModule

having a closer look at your class there seems to be a space between server and .jaas

(This happens often when you type the classname yourself! It happend to me as well

Try correcting this by accessing Security Provider > Runtime > User Management

Klick on Manage Security Stores (Switch to Edit Mode)

Unfortunately you cannot edit the Login Module and change the class name so remove the HeaderVariableLoginModule from the list and add it again. Make sure that the class name is correct (com.sap.security.core.server.jaas.HeaderVariableLoginModule) no spaces!!

This should help (Don't forget reward points for helpful answers )

Cheers

Former Member
0 Likes

Hello Marcel,

Indeed, I found the error in the login module, there was a space inserted and it couldn't load the class. I am now able to authenticate with http header on a simple jsp which has been deployed on the Java Stack, I can see that SAP Logon Ticket has been created. Now I am trying to test the SSO on a backend BSP application. Backend system is configured to accept logon tickets (transaction RZ11) and has the certificate of the Java Stack (transaction strustsso2). I am now using the jsp application redirect but it doesn't seem to forward the SAP Logon ticket as I get for result an error page indicating that SSO is not possible:


SSO logon not possible; logon tickets not activated on the server 
 
 Choose "Logon" to continue A dialog box appears in which you can enter your user and password 
 
 No switch to HTTPS occurred, so it is not secure to send a password 
 

Is it because with the jsp I am not passing the sap logon ticket in the header?

Former Member
0 Likes

Hi Tanguy,

SSO logon not possible; logon tickets not activated on the server

this looks more like login tickets are not being accepted by your server!

Which parameter did you set in rz11?

It should be

login/accept_sso2_ticket with value 1

Do you have that?

How did you verify that the Logon Ticket has been issued?

If you imported your engine certificate into SAP Backend using strustsso2 (certificate List and ACL) and you are sure that the Ticket is in your browser (Cookie MYSAPSSO2) all you have to do is call the Backend BSP manually using the same Browser Session. This way you can see if it works and if it does it will also work when redirecting from your JSP.

The redirect is followed by your browser and since the Cookie is stored in your browser it will also be sent to your backend

BUT: The cookie will only be sent to your backend if it has the same domain suffix as your engine. So make sure you call your hosts with full qualified name

e.g.

your engine host:

http://enginehost.domain.com/irj/portal dont'use http://enginehost/irj/portal

Backend

http://sapbackend.domain.com/sap/bc/....

otherwise it won't work (e.g. your backend uses domain2.com instead of domain.com)! To see if the Cookie is actually sent you can use Firebug or HttpFox. These are free extensions for Mozilla Firefox. You can install them and you will be able to see the HTTP Traffic without using any sniffers like Wireshark or tcpdump.

Cheers

Former Member
0 Likes

Hello Marcel,

thx for your input, I am still trying to make this work. We're close to the goal:

I have checked configurations in RZ11 and STRUSTSSO2, and everything seems ok.

I copy/paste my dispatcher http log here under, we see that the http header parameter is passed, we see that I get http redirection request with the SAP Logon Ticket but finally we are not correctly redirected, it might be the last thing you explained about the domain suffix.

My engine host:

http://enginehost.aaaa.domain.com:50000

My backend:

http://sapbackend.bbbb.domain.com:1080


[1215681331821][Jul 10, 2008 11:15:31 AM ] - CLIENT: 34304, REQUEST: 
{GET /SSOredirect/SSOredirect.jsp?redirectURL=http%3A%2F%2Fsapbackend.bbbb.domain.com%3A1080%2Fsap%2F... HTTP/1.1
http_header: MYHEADER
User-Agent: Java/1.6.0_05
Host: enginehost.aaaa.domain.com:50000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

}
[1215681331961][Jul 10, 2008 11:15:31 AM ] - CLIENT: 34304, REPLY: 
{HTTP/1.1 302 Found
Set-Cookie: MYSAPSSO2=AjExMDCIAAdkZWZhdWx0AQAJREVNT19NT1NTAgADMDAwAwADSkQyBAAMMjAwODA3MTAwOTE1BQAEAAAACAoACURFTU9fTU9TU%2F8BBDCCAQAGCSqGSIb3DQEHAqCB8jCB7wIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBMYHPMIHMAgEBMCIwHTEMMAoGA1UEAxMDSkQyMQ0wCwYDVQQLEwRKMkVFAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTAwOTE1MzFaMCMGCSqGSIb3DQEJBDEWBBT%2FQM2W6CXJebxMK0E1pgU!nxmzCDAJBgcqhkjOOAQDBC4wLAIUSq4ZWgQlk66K73RVmMXTAW%2FeCxoCFAnJ8F0q!HwzmtqeWj2RdFYve3dA;path=/;domain=.aaaa.domain.com;HttpOnly
Set-Cookie: JSESSIONID=(J2EE7854200)ID0664447950DB00280758538171157282End; Version=1; Domain=.aaaa.domain.com; Path=/
Set-Cookie: saplb_*=(J2EE7854200)7854250; Version=1; Path=/
Server: SAP J2EE Engine/7.00
Content-Type: text/plain
Location: http://sapbackend.bbbb.domain.com:1080/sap/...
Content-Length: 0
Date: Thu, 10 Jul 2008 09:15:31 GMT

}
[1215681331961][Jul 10, 2008 11:15:31 AM ] - CLIENT: 34304, REPLY: 
{}

Where do you think the problem could come from?

Again, thanks for your help.

Regards,

Tanguy

Former Member
0 Likes

Hi Tanguy,

yes seems like we are really close.

Having a look at your dispatcher log it really seems like you are having problems with your domains but we can solve this:

You wrote that your backend is in domain

bbbb.domain.com

while your portal is in

aaaa.domain.com

and your cookie is issued for domain

.aaaa.domain.com

This means that this cookie will never be sent to your backend

You can configure your cookie domain by adjusting the relax domain in the UME Configuration

Have a look at this documentation under help.sap.com

http://help.sap.com/saphelp_nw70/helpdata/EN/5e/473d4124b08739e10000000a1550b0/frameset.htm

You have to achieve that your cookie will be issued to .domain.com so it will be sent to your backend as well.

- Start the Visual Admin

- Start the ConfigurationAdapter Service

- Navigate to "cluster_data" > "server" > "cfg" > "services" > "PropertySheet com.sap.security.core.ume.service" and adjust the value of the UME Parameter "ume.logon.security.relax_domain.level" (default is 1 and in your case it should be set to 2 because it relaxes counting the dots from left to right so sapbackend.bbbb. will be relaxed and domain.com remains)

- Save your changes

The cookie should now be issued to .domain.com

Another way to achieve this is to configure the cookie domain in your web-j2ee-engine.xml (You can find it in ConfigurationAdapter under "cluster_data" -> "server" -> "persistent" -> "servlet_jsp")

see http://help.sap.com/saphelp_nw70/helpdata/EN/4e/a4ff3040d9924fb87686612001d425/frameset.htm

Also see SAP Note (791765)

This could look something like that:

<cookie-config>
    <cookie>
        <type>SESSION</type>
        <domain>.domain.com</domain>
    </cookie>
    <cookie>
        <type>APPLICATION</type>
        <domain>.domain.com</domain>
    </cookie>
</cookie-config>

SAP Note 791765 describes where to put this in your web-j2ee-engine.xml

The first approach should fit your needs for now!

Hope this finally helps (Don't forget my points this time )

Cheers

Former Member
0 Likes

Hello Marcel,

I've done the change but it still doesn't work grr. In my java application which calls the jsp with http header, I realized that I am always getting a response in the console with this header and the html page of SAP that says:

SSO logon not possible; logon tickets not activated on the server

I have to correct also and say that it's a SAP Netweaver Java Stack 7.0 that issues the SAP Logon Ticket and that there are no SAP Portal installed on it.

Here follows the http header I get as response on my client machine


null : [HTTP/1.1 200 OK]
content-type : [text/html; charset=utf-8]
cache-control : [no-cache]
set-cookie : [sap-usercontext=sap-client=400; path=/]
content-length : [13096]
server : [SAP Web Application Server (1.0;700)]
pragma : [no-cache]

Here is the dispatcher log after restarting java stack and redoing the test (we can see that the MYSAPSSO2 ticket has the asked domain):


[1215695406114][Jul 10, 2008 3:10:06 PM  ] - CLIENT: 1024, REPLY: 
{HTTP/1.1 302 Found
Set-Cookie: MYSAPSSO2=AjExMDCIAAdkZWZhdWx0AQAJREVNT19NT1NTAgADMDAwAwADSkQyBAAMMjAwODA3MTAxMzEwBQAEAAAACAoACURFTU9fTU9TU%2F8BBTCCAQEGCSqGSIb3DQEHAqCB8zCB8AIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBMYHQMIHNAgEBMCIwHTEMMAoGA1UEAxMDSkQyMQ0wCwYDVQQLEwRKMkVFAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTAxMzEwMDZaMCMGCSqGSIb3DQEJBDEWBBTOMz0pnQwNYObsQRl9A7P4fwRj!zAJBgcqhkjOOAQDBC8wLQIUdvNZbOJ8bMawUzPUTKt7OvVBTiwCFQCcrTj22hLz2dbtaGvKuByMP28mmA%3D%3D;path=/;domain=.domain.com;HttpOnly
Set-Cookie: JSESSIONID=(J2EE7854200)ID0437245150DB00271490616215334563End; Version=1; Domain=.aaaa.domain.com; Path=/
Set-Cookie: saplb_*=(J2EE7854200)7854250; Version=1; Path=/
Server: SAP J2EE Engine/7.00
Content-Type: text/plain
Location: http://sapbackend.bbbb.domain.com:1080/sap/...
Content-Length: 0
Date: Thu, 10 Jul 2008 13:10:06 GMT

}
[1215695406114][Jul 10, 2008 3:10:06 PM  ] - CLIENT: 1024, REPLY: 
{}

Former Member
0 Likes

Maybe I should activate the http logs on my sapbackend system: icm/HTTP/logging_<xx> but I think it might have an impact on performance as that system is used by a lot of developers.

Former Member
0 Likes

Hi again,

if the client response you posted is the one returned by your backend this one is not interesting. Can you post the response that reached the client when accessing the SAP J2EE? Just to make sure that the response seen on the client matches the one logged on the dispatcher.

Do you have more than 1 application server on your backend?

Cheers

Former Member
0 Likes

Hi again Marcel, thanks for helping me really

The answer I get back from my Java Application on my client when calling the JSP SSORedirect is as follows:


null : [HTTP/1.1 200 OK]
content-type : [text/html; charset=utf-8]
cache-control : [no-cache]
set-cookie : [sap-usercontext=sap-client=400; path=/]
content-length : [13096]
server : [SAP Web Application Server (1.0;700)]
pragma : [no-cache]

Here is the html code saying that: SSO logon not possible; logon tickets not activated on the server

Should I normally see the 302 http reply?

And yes we have several Backends,

Regards,

Tanguy

Former Member
0 Likes

Hi,

this is the reply you are getting from your Backend. Otherwise the Server Header should contain

SAP J2EE Engine/7.00

instead of

[SAP Web Application Server (1.0;700)]

as you can see in your dispatcher log. This is already the response you are getting from your backend after bering redirected to

http://sapbackend.bbbb.domain.com:1080/sap/...

by the redirect application. Can you see the 302 response in your client before actually following it?

(see dispatcher log)

Nevermind:

If you have more than one backend make sure that all application servers accept the logon tickets. If you activated this only in one profile (INSTANCE Profile) and you are using the message server port to access the backend you are probably accessing one server with the parameter not active??

Try the following:

After calling the J2EE that issues the logon ticket for .domain.com as you can see in the dispatcher log try to directly access (server http port, not message server port) any resource in the application server of which you know the parameter login/accept_sso2_ticket is set to 1. Just type the url and access any BSP on your WebAS that normally would ask for authentication and see what you get here

Cheers