I am reading through the WebFOCUS Security manual to learn how to secure one self-service application while leaving other self-service applications unsecure on the same WebFOCUS server. I did a search on the forums to find suggestions but didn't see anything that seemed to fit the bill for me. Did I miss any threads that gives insight on how to do this? Has anyone done this before?

I am using WebFOCUS on the Windows platform with IIS as the Web Server piece. All components of WebFOCUS are installed on the same Windows box.

Any suggestions will be greatly appreciated.

I am assuming that you are using a generic userid/password to talk to the reporting server. If that is the cause you can use the ibi_html/wfsignon.html file to have your secured apps require the users to signon with there ID/PW's then you can check to see if the connected user has access to the procedure.

Hope this points you or gives you some direction.

I have been looking at using the WebFOCUS logon page to get the logon information. However, I am also experimenting on how to lock down access to a particular application so that a person cannot get around the logon security by accessing the HTML files directly or issuing a call to WebFOCUS to execute a FOCEXEC directly.

Right now I am adding script commands into the SITE.WFS to control all requests to WebFOCUS to make sure they include specific pieces of required information. I am also dynamically adding the directory for the application to the APP PATH with a profile FOCEXEC via the _site_profile setting. Keeping the directory off the APP PATH until needed prevents people from running the FOCEXECs directly. I am trying to code the SITE.WFS file so that people are forced to logon before the application directory is added to the APP PATH.

I hope this makes sense. I haven't quite got it all worked out yet. Hopefully I will find a solution which I can then post here for others to use if needed in the future.

I mainly am coming up with an idea and then I am thinking about how I would break it. Then I go back and try to close that hole while at the same time trying to not affect applications that do not have access restrictions.

Just another note, I do not need to use DBA because all authorized users can see all data. Therefore I only need to concern myself with access to the application.

I almost have this working. The only problem is that the IBIC_user variable seems to be NULL or blank after a successful logon. I am doing an <IF> test on IBIC_user in the SITE.WFS file to make sure a value exists but it is not populated with the user id for all subsequent report requests after the initial successful logon.

Has anyone had this problem with WF7.1.3 and found a way around it.

Have not had this problem. But, let me describe what we are doing at one location. Using the DOT NET NUKE portal the users are forced to login. Then a domain level cookie is being created because the portal is on a different virtual web server then the WebFOCUS client. Having a domain level cookie allows the to sites to share the cookie. The cookie is then passed to the Reporting Server using CopyCookieVarToWFVar in the site.wfs. Then in each focexec we include a securty check focexec and pass in variables like the cookie, facilityid and reportid. The security focexec issues a SQL request passing these values as where statements, if a record is returned then the user has access to; 1) run the report, 2) access the data for the requested facility. If no records are returned then access is denied and an html page is displayed telling the user they do not have access to the requested information. You said you don't need DBA level security, WebFOCUS DBA level security can be used to control access to the data without controling field and/or value level. just by using

USER=TOM,ACCESS=R,$
.....
USER=SAM,ACCESS=R,$

then if the user is not listed in the DBA section they cannot access the data.

Hope this Helps

How are you preventing someone from altering the cookie?

We are not the COOKIE is a very long string that is the GUID created by the DOT NET NUKE application we just create a cookie to match it. The cookie ie readable but not understandable. Another option is to use a JAVA Session variable.