Skip to Content

I recently ran into this problem, which I finally and luckily came to fix it myself!

http://forums.sdn.sap.com/post!reply.jspa?messageID=9164911  

Here’s the full story, which may help someone else, hopefully. 

Users accessing /irj/portal are authenticated by the external application using the Http Header Variable mechanism: the external app is basically writing USER=Uxxxxx in the Http Header when redirecting to /irj/portal upon successful auth.

The /irj/portal is configured to trust this variable, and to create a logon ticket based on that value.

This works if you create your own variant (for the impatient: see last pciture) of the “ticket” login template authentication stack in the Security Provider (either in Visual Admin or NWA depending whether you are on WebAS <=7.0 or <=7.1 respectively). Read on.

The problem

Why is this wonderful authentication mechanism not working with my brand new shining Web Dynpro application if I run it directly, that is without going through /irj/portal, which btw is a strong requirement? It’s a mobile Web Dynpro, man, aimed to run on BlackBerry devices… Can you imagine /irj/portal on a 320×240 screen? Weird. 🙂

Basically issues with my WD app preventing the same behaviour are two:

(1) despite what Basis guys are claiming, the external app is returning ther USER variable ONLY for /irj/portal, and not for any web app running on that Portal. We realized that by simply running a “dump” jsp which is writing down almost everything (headers, req parameters, cookies:

<u>code below</u>): the USER was set with a dummy fixed value, while the real user was indeed written with REMOTE_USER variable... </div><pre><%@ page language="java" %><br/>

<%@ page import=”java.util.” %><br /><html><br /> <head/><br /> <body><br />  <hr><br />  HEADERS<br><br />  <% <br />  Enumeration e1 = request.getHeaderNames();<br />  if (e1!=null)<br />  while (e1.hasMoreElements()) {<br />   String n = (String)e1.nextElement();<br />   String v = request.getHeader(n); %><br />  <%=n%> = <%=v%><br> <br />  <%}%><br />  <hr><br />  REQUEST PARAMETERS<br><br />  <%<br />  Enumeration e = request.getParameterNames();<br />  if (e!=null)<br />  while (e.hasMoreElements()) {<br />   String n = (String)e.nextElement();<br />   String v = request.getParameter(n); %><br />  <%=n%> = <%=v%><br> <br />  <%}%><br />  <hr><br />  COOKIES<br><br />  <% Cookie[] c = request.getCookies();<br />   if (c!=null)<br />    for (int i = 0; i < c.length; i++) { %><br />    <%=c[i].getName()%> = <%=c[i].getValue()%> <br><br />  <%}%><br /> </body><br /></html> </pre><div>Bingo! So let’s find out how to make it work this way.</div><div> </div><div>(2)* I wasn’t able to find a way to change the authentication mechanism (let’s call it “auth modules stack”) for my single Web Dynpro app: in other words, the Security Provider is showing a “generic” webdynpro/dispatcher item, which is affecting every Web Dynpro app. Am I going to change this behaviour in this huge Portal implementation for all Web Dynpro applications, both standard and custom? Not at all. Unpredictable results are round the corner.

So a more conservative (but effective) approach is to write a very simple web app – a jsp, in fact – (Web Module DC) and deploy it with an Enterprise Application DC. In this way, you can exactly find (and change according to your needs) one item related to your web app (the Enterprise Application) in the Security Provider service.

NWDS

The solution

First of all, you need to make your web app “secure”, by enabling authentication: there’s a lot of standard doc in the SAP Library around this matter, but for the sake of simplicity I have followed

this wiki

, in the first part called “Authentication Setup”.

What needs to be changed over there to do the trick? We simply need to tell the Security Provider that the user is to be taken from the REMOTE_USER http header variable, instead of the USER variable. Simple, isn’t it? (yeah, once you know)

 

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply