Hi;

We have our WebFOCUS reporting server installed on Windows 2003 box and client on HP-UX 11i. We have configired reporting server to do LDAP
security. We are using Novel e-Directory.

We have developed some standalone reports which will be accessed from our browser based J2EE applications. All these applications have its own signon screens and the logon process is validated against LDAP. Once the user has logged-on to the application, he/she will click a link to run a WebFOCUS report on WebFOCUS server. So ideally, WebFOCUS will show the signon screen. Since the user is already validated against LDAP, we need to bypass the WebFOCUS signon screen there by implementing single signon.

I wants to know if i can pass a trusted LDAP user who is already authenticated to the reporting server.

Anyone suggestion?

Thanks

-Maria
------------------------------------------------
Dev: 7.6.4 client on HP-UX. 7.6.4 server on Win 2003.

We approach this two different ways. For some of our applications that we want to monitor on the server which userid runs the app, we pass the IBIC_user and IBIC_pass variables populated with the login credentials received from signing in to the app.

For many of our other applications, we only care that they authenticate to the application, but don't really care who runs the procedure on the WF side. Any variables that are passed are completely validated on the java app side, so we created a static user ID in e-directory that is passed in the IBIC_user and IBIC_pass variables. That static user runs all the reports, regardless of who was actually authenticated in the app.

Thanks Darin.

Can you give a example how to pass the login credentials received from signing in application to IBI_User and IBI_pass? Or can you point out some documents for me?


Regards
-Maria

We preform something similar in which we use the following code below in our ibicommd.wfs file. As Darin stated we also pass a static id for the user.



REMOTE_USER=&WF_REMOTE_USER
REMOTE_ADDR=&REMOTE_ADDR
WEBSERV=&SERVER_NAME
WEBPORT=&SERVER_PORT

WF 7.6.10 /IIS 6/ JBoss Enterprise 4.3
Windows XP SP 2/Windows 2003 Server
MVS 7.3.3

I'm not very proficient in Java, and without details of your app, can't be very speciific. But somewhere in there (due to the fact that you are authenticating users in the app) you are capturing the user id and pass. You can take these variables/properties/objects and use them in construction of the URL string behind the link that calls the WF report. The java programmer will have to give the details of where those values are.

&IBIC_user and &IBIC_pass are simply parameters like fex name or any others, but the server sees them and can authenticate more or less "on the fly" by their presence in the URL string. There are several of these "hidden" parameters (&IBIF_ex, &IBIC_serve, etc) that are also included in the URL.

Thanks.

In our J2EE application, we just provide the static link which points to a html page hosted on WebFOCUS client.

From my understanding, the link should include authentication variables obtained from LDAP and pass it to webfocus by &IBIC_user and &IBIC_pass ? Is that correct?

Regards

-Maria

I missed the purpose of the link there. I was assuming that when you said "they click on a link to run a report on the WF server" that the link was an actual servlet/cgi call to execute a report and that by clicking on it, they were causing a report to be run. (This is how we approach the problem at our site. All parameters and authentication are done within the app with no intermediate steps to allow them to change any values.) Otherwise, they could view source on the HTML page, see the contruction of the URL and run the report with any parameter values whether or not they are authorized to by their user id.

What is the content/purpose of the HTML page? Is it a WF launch page to gather additional parameter values?

In your current case the passing of any parameters is irrelevant because you are only going to an HTML page - no way to accept parameters there.

It might be possible to include the content or purpose of the HTML page within your app and then the link with the credentials embedded would work. I would need to know more about what the HTML page is.

The only way I see you integrating your current case with a single sign-on is to have your app set appropriate WF cookies which could be later read and used for authentication. I know WF has the capability to do that, but having never gone there, someone else would need to explain about that. The use of WF cookies is also explained in the documentation.