#28317

OK, in our development environment I can detect the presence of the Authorization header, base64 decode the username and password and then use PD4MLs support for basic authentication. It would be easier to just forward the Authorization header though. I need to use the identity of the user who made the original request as the images and charts are personalised. However, that doesn’t help me in our production environment.

You are correct that the browser does not set the iv-user header, as I said, it is the Tivoli Access Manager proxy server that does this. It’s quite standard practice for a security proxy to use such a header to pass information about authenticated users to an application server.

The browser maintains the session with the security proxy using a cookie.

I want PD4ML to send its requests for images directly from the application server to the application server, and not via the security proxy. There are several reasons for this, but mainly that there is no network path that allows a request from the application server out to the security proxy and back to the application server. Further, even if there was a such a network route sending the session cookie used between browser and security proxy would not work. It would not be a very good security solution if you could replay the cookie and get an authenticated session from a different client on a different host!

So, for this to work, I need to be able to forward headers recieved in the original HTTP request when requesting images etc. to be included in the PDF. If that’s not possible, then I’ll need to look at a different architecture.

Out of interest, what HTTP request context does PD4ML.useHttpRequest() transfer if it doesn’t include the HTTP headers ? Basically, what does it allow me to do that isn’t already covered by other methods such as PD4ML.useServletContext() and PD4ML.setCookie() ?

Regards
Simon

#28315

In the regular non-PDF scenario you describe, consider when the site serving the HTML and images is protected using Basic Authentication. In that scenario after you’ve logged in to get the main HTML page, each request for the images contain the Authorization header with a value such as “Basic c2ltb246c2ltb24=”. It doesn’t use sessionids or cookies to identify the user.

In our scenario the Tivoli proxy in front of our application server adds the iv_user header to requests that are forwarded to the application server. The application server looks for that header to identify the user.

To get this to work with Flying Saucer / xhtmlrenderer I wrote a custom UserAgentCallBack which copied the request header from the initial request through to those being used to generate the PDF. This solved the authentication problem for both Basic Auth (as we have in our development environment) and for the custom Tivoli header we have in our production environment.

Is there a way to do something similar with PD4ML ?

Or, preferably, can PD4ML.useHttpRequest() be made to read the headers in the HTTP request provided and use them in requests being made by PD4ML to generate the PDF?

Regards
Simon

#28313

OK, a little more information about our environment.

We have Tivoli Access Manager (TAM) in front of Day Communique (CQ). TAM handles authentication, it validates login details and then sets a trusted header in the request that’s forwarded to CQ. If the header is set, CQ checks it matches a user account in that system and applies its own authorisation before serving the requested page.

The page doing the PDF generation resides on the CQ server, as do the images and chart servlet that I reference in the HTML I want to use to generate PDF.

The URLs in the HTML address the CQ server such that requests bypass TAM.

For this to work, the HTTP header containing the user authentication information needs to be included in the request that PD4ML makes to retrieve the images.

We don’t use JSESSIONID or cookies to identify the user to CQ, only .

Regards
Simon

[Author]

Posts