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

Question

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

Answer 1

Hi Tanguy,
to tell you the truth I'm really unsure about what you are trying to achieve. When I started posting to your thread I thought all you wanted was trying to access your J2EE engine via Browser and authenticate against the engine using HTTP Header Variables. Nevermind:
Here are some answers to your question:
in fact I did succeed, the problem was that even after domain-relaxation done by the J2EE, I had to change the domain of th SAP cookie to the bbbb.domain.com to be understood (I would have thought that all hosts in/under domain .domain would have accepted such a cookie but it seems that no...).
The server does not care about the domain because Cookies in an HTTP Request do not contain any domain information. The domain is just important when the Cookie is set by the server so your Client (Browser) will know in which cases the Cookie may be sent or not. So if your domain is xxx.yyy.domain.com and your cookie is issued to .domain.com then your Browser will definitely sent it to all hosts under .domain.com (This includes xxx.yyy.domain.com etc.)
My current scenario is: in a first request get a SAP Logon Ticket from the Java Stack, then change its domain and then directly call the backend with it.
You can do that but there is no Client involved in this scenario. So this is useful if you just want to test the functionality (e.g. authentication to J2EE using Header Variables (This works finally!!!) and then use the fetched Logon Ticket to test SSO against any trusted Backend!!)
So everything's is in a Java Client application without using any redirection.
If I understand you, you're solution is from the Browser call a servlet (which is deployed on the Java Stack and has no authentication schema) by passing to it our http header.
No, you should initially authenticate somewhere! I thought that maybe you had some resource you access before accessing the Java Stack. This could be any application (e.g. deployed on a Tomcat or JBOSS or other server or if you like even SAP J2EE). After authenticating there you are aware of the username and could use it to  procceed (e.g. Authenticate against the J2EE using the same user and HTTP Header authentication for that particular user!)
That servlet will transfer the http header (with the HttpClient app) in order to get from the Java Stack a SAP Logon ticket, and then to redirect to the resource and by sending back the cookie in client browser. Am I correct?
This was just a suggestion because I realized that there was no Client ever involved in any of your testing (looked strange to me!). I was just thinking that it would be easier for you to just get the Cookie into your Browser so your Browser would do the rest for you (in your case finally send the Logon Ticket Cookie to your Backend to test SSO using Logon Tickets!).
The AuthenticatorServlet somehow serves as a Proxy to your client because your client is not able to set the Header Variable. That's why I initially suggested to use a Proxy (e.g. Apache) for that purpose. The problem is just that if you use a Proxy you will have to tell it somehow which username it should set in the Header Variable (e.g. using a URL Parameter or using a personalized client certificate and fetch the username (e.g. cn=<username> from the certificate!)
This way of doing would simplify the calls for sso for each new application needing authentication, instead of having all code each time in it...
I'm stuck again! Do you want to authenticate an End User or do you want to authenticate an application that needs to call any resources in your Backend that requires authentication?
So my problem now, is how to call the servlet from the client browser:
I'm trying to call my servlet from the browser but I don't succeed. I am able to understand how to reach a jsp from the Java Stack, but not to reach a servlet. I don't find the path to my servlet:
<FORM method="POST" action="SSORedirect2" >
A JSP is a servlet too. There is just no JAVA Class involved!
You do not need any POST Request to invoke a Servlet.
I see that my servlet is deployed, but I don't how what path to give to my form to invoke the servlet, here follows my web.xml
  <?xml version="1.0" encoding="UTF-8" ?>
  <!DOCTYPE web-app (View Source for full doctype...)>
- <web-app>
  <display-name>WEB APP</display-name>
  <description>WEB APP description</description>
- <servlet>
  <servlet-name>SSOredirect2</servlet-name>
  <servlet-class>com.atosorigin.examples.AuthenticatorServlet</servlet-class>
  </servlet>
- <servlet>
  <servlet-name>SSORedirect2.jsp</servlet-name>
  <jsp-file>/SSORedirect2.jsp</jsp-file>
  </servlet>
- <security-constraint>
  <display-name>SecurityConstraint</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>
If you have an AuthenticatorServlet Class all you need is to add the Servlet Mapping in your web.xml file
e.g.
<servlet>
  <description>
  </description>
  <display-name>AuthenticatorServlet</display-name>
  <servlet-name>AuthenticatorServlet</servlet-name>
  <servlet-class>com.atosorigin.examples.AuthenticatorServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>AuthenticatorServlet</servlet-name>
  <url-pattern>/AuthenticatorServlet</url-pattern>
</servlet-mapping>
You can directly call the Servlet in your Browser by calling the URL provided in the url-pattern of your Servlet mapping ( in this case /AuthenticatorServlet). The engine will invoke the Class "com.atosorigin.examples.AuthenticatorServlet" in the background and do whatever you defined there!
I have also to pass my http header and the redirectUrl in the GET request.
If you like! I just suggested this for testing purposes. As I stated before you need a way to tell your proxy (or in your case AuthenticatorServlet) which user should be set when calling the Engine in order to authenticate using HTTP Header. You could use the URL Paramater to define the user you actually want to use when you set the Header Variable.
I just introduced the redirectURL because you were talking about redirects all the time. So if you finally want to call the Backend you could define the Backend URL in the redirectURL Parameter and the Servlet will make sure that you are redirected to this location after the whole process!
Thx for your input very helpful,
But again 0 points
Cheers