[SOLVED] Launching to self-service reports from extranet portal built using JSP page

We run several report in a similar fashion, but to secure them properly, all of the parameter selection is handled by the JSP page. The URL is formed behind the scenes with all the appropriate parameter values along with a static set of credentials (set up to allow our "internet" users to access reports from our secure server). I would (obviously) suggest that those credentials be completely hidden from the users, but we also hide all parameter calues from the user as well so they cannot read the URL (via view source or some other way) and modify them to run for some other values that are not alowed for that user.

That would basically eliminate them from using the HTML page from layout painter because that could be easily viewed before submitting the form.

Regards,

Darin

In FOCUS since 1991
WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex
Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex
WF Client: 77 on Linux w/Tomcat

Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007

Ignored post by Darin Lee posted

Virtuoso

posted

There are so many ways to do this. Before I suggest anything however, can you please tell me if your external portal is JSR 168 compliant?

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

posted

Thanks Dhagen,

I will find out this morning and respond back as soon as I can.

Do you agree with the above two posts?

Virtuoso

posted

Yes and no. Darin's comment is kind of vague, so it is really hard to tell what he is typing (for me anyway). My ears always perk up when people go on about hiding the URL. I don't really see the benefit of hiding it! If your security can be compromised by knowing a URL, or a view source, or something as simple as that, then maybe it is time to re-architect your security model.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

posted

The question I got from my JAVA guy is what part needs to be JSR 168 compliant?

quote:
Originally posted by dhagen:
There are so many ways to do this. Before I suggest anything however, can you please tell me if your external portal is JSR 168 compliant?

Virtuoso

posted

There really isn't a part, it either is or is not. My guess here is that this is a custom built portal that was purpose built, with no real concerns or requirements for open technology concepts. That's still ok, it just limits what you can do.

So, if you want to pass the user in a secured way, I would recommend building your own multi-factor authentication. You could then use proxy accounts to connect to the WFRS. The steps would be as follows:

1. Have the portal write the following to a database table:
- Userid, DateTime Stamp, Unique Id, User's remote ip address.
2. When the call is made to WF, you would then pass the Unique Id to the request.
3. Build a Java Filter that you should implement in the WF web application that will:
- grab the Unique Id with the request.
- Query the table from step 1 and retrieve the Userid, DateTime Stamp, and Remote IP address.
- The filter would then verify:
- The Time is less then 2 seconds old.
- The Remote IP's are the same.
- if all is ok, then the Userid should be written to the java session (that way the next request will not have to repeat the query).
- Wrap the HttpRequest and override the getRemoteUser() method and have it return the new Userid.

Now you can configure the WF client to trusted mode with the remote user as the valid userid.

If this sounds like too much, you might want to pass it to your Java guy. He will be able to make sense of what I just typed.
-

This message has been edited. Last edited by: dhagen,

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

posted

Thanks Dhagen,

I spoke with our Java guy and he made a proposal to pass the variables (session id {key}, user id, datatime stamp) to a proxy. I guess that is what you stated in #3, building a java filter. It would seem that we can run this java servlet in the same tomcat container as a servlet and would do the options that you stated in #3.

However, I'm still a little unclear as to how the HTML parameter page will need to change. Do we have to modify the HTML page or because the java filter will handle the authentication of the user and session and then could probably launch to the HTML page via a POST.

Then would we be secure after that point? Would the user be able to copy that URL of the parameter page and launch to another report via scraping the URL.

quote:
Originally posted by dhagen:
There really isn't a part, it either is or is not. My guess here is that this is a custom built portal that was purpose built, with no real concerns or requirements for open technology concepts. That's still ok, it just limits what you can do.

So, if you want to pass the user in a secured way, I would recommend building your own multi-factor authentication. You could then use proxy accounts to connect to the WFRS. The steps would be as follows:

1. Have the portal write the following to a database table:
- Userid, DateTime Stamp, Unique Id, User's remote ip address.
2. When the call is made to WF, you would then pass the Unique Id to the request.
3. Build a Java Filter that you should implement in the WF web application that will:
- grab the Unique Id with the request.
- Query the table from step 1 and retrieve the Userid, DateTime Stamp, and Remote IP address.
- The filter would then verify:
- The Time is less then 2 seconds old.
- The Remote IP's are the same.
- if all is ok, then the Userid should be written to the java session (that way the next request will not have to repeat the query).
- Wrap the HttpRequest and override the getRemoteUser() method and have it return the new Userid.

Now you can configure the WF client to trusted mode with the remote user as the valid userid.

If this sounds like too much, you might want to pass it to your Java guy. He will be able to make sense of what I just typed.
-

Virtuoso

posted

quote:
Originally posted by Joseph:
However, I'm still a little unclear as to how the HTML parameter page will need to change. Do we have to modify the HTML page or because the java filter will handle the authentication of the user and session and then could probably launch to the HTML page via a POST.

Your assumptions are correct in that you should not have to modify the HTML page at all, as the filter will handle the authentication. Secondly, I would always recommend that you use a POST process where ever you can.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted