I'm interested in your suggestions.

We're a university fairly new to WebFOCUS and the Dashboard.
We have several standard reports that are based on a department code but would like to have users only have access to their department info. The reports have this as a variable. It doesn't look like there's an user attribute in MR that we could put in the department code for each user.

We don't want to have few dozen domains with the same reports except the department is hardcoded. That would be difficult to maintain.

One thing we were thinking was creating a hold table that would hold a password for each individual department. And prompting them for the department code and password and if they have the right combination they'll get their report.

We currently don't have report caster, but hope to in the near future. Would that help?

What are others doing?

Thanks,
Nate

This message has been edited. Last edited by: <Nate Conn>,

Nate :
You could also try having the UserId-Department relationships in a table (MS-SQL,DB2,etc) to limit access.
#1> When the user logs-in, you check the user-id against this database, build a drop-down/multi-select HTML box with dept. list and present it on a launch page, so the user knows what he can get to.
#2>Else, you chould check the access after the user submits a report. Process the report if the UserId-Dept combo is valid, or send back a message to the user saying you are NOT allowed to run reports on this department.

This way, it is one less password for the Users to remember, for you to maintain, and no risk of a password being ever compromised. When access is to be revoked, you just delete the User's record from the database.

If you would want to use this validation technique across various applications, you can have the database have 3 columns -- (App-Type,User-Id & Dept).

Hope that helps,
Sandeep Mamidenna.

There are several was to address this issue. The first that comes to mind depends on how the users are connecting to the reporting server. If MRE/Dashboard is authenticated to the reporting server then you know who is connecting to it. Then you could use WebFOCUS DBA Level security. This would create a where statement unknown to the use that would limit what they could have access to. Please Check out the WebFOCUS Security and Administration Guide.

There are even WebFOCUS Security Exist that could be used to get the user department and pass it to the Reporting Server as an amper variable. The WebFOCUS Security and Administration Guide also talks about the WebFOCUS Security Exit.

Another Option is to contact your support branch and see if they could provide assistance this may be something they charge for.

Just Suggestions
Hope this helps

Thanks for the suggestions.

I'm wondering if they'll work though...we're using LDAP and instead of creating users in two places (MR and Reporting Server) we just create them in MR and pass them as a single user to the reporting server.

How long will that MR user variable persist and will the Reporting Server know this to work in a standard report in the dashboard?

Thanks,
Nate

Nate,
I also work for a university where we needed to limit what depts and funds the dashboard users could run reports against. Our first thought was the DBA Security, but you need to create a profile for each user, and you need to turn SQLPassthrough off for the user because SQLPassthrough doesn't use the mfd's.
We've decided to go with Reporting Objects. In the reporting objects we create a hold file which contains all the funds that the current user can view (we determine current user by &IBIMR_user). We then create reporting objects for the mfd's that are built by joining the hold file to the original mfd, thus limiting the data for each mfd. We will create a new role in MRE that will only be able to see the Reporting Objects and not all the mfd's within the domain, forcing them to use the reporting objects. If this sounds like what you're trying to achieve you can email me at lfrerker@slu.edu.

We only set our users up in MRE via the MRE Administration screen. We use the &IBIMR_user in reports also, which are ran within Dashboard, and it works great. Maybe something is different in your configuration with LDAP. We're on Linux.

The DBA Security system is meant to solve this issue. You can control it from the MRE Admin console, so that the database password is passed along every time the user makes a request to that database.
A sample MFD is shown in the WF Doc, note the VALUE area. That is where the FILTER is placed on any password...
Example: Implementing Data Source Security in a Master File
The following is a Master File that uses security features:

FILENAME = PERS, SUFFIX = FOC,$SEGMENT = IDSEG, SEGTYPE = S1,$ FIELD = SSN ,ALIAS = SSN ,FORMAT = A9 ,$ FIELD = FULLNAME ,ALIAS = FNAME ,FORMAT = A40 ,$ FIELD = DIVISION ,ALIAS = DIV ,FORMAT = A8 ,$SEGMENT=COMPSEG, PARENT=IDSEG, SEGTYPE=S1,$ FIELD = SALARY ,ALIAS = SAL ,FORMAT = D8 ,$ FIELD = DATE ,ALIAS = DATE ,FORMAT = YMD ,$ FIELD = INCREASE ,ALIAS = INC ,FORMAT = D6 ,$ENDDBA=JONES76,$USER=TOM ,ACCESS=RW, $USER=BILL ,ACCESS=R ,RESTRICT=SEGMENT ,NAME=COMPSEG ,$USER=JOHN ,ACCESS=R ,RESTRICT=FIELD ,NAME=SALARY ,$ NAME=INCREASE ,$USER=LARRY ,ACCESS=U ,RESTRICT=FIELD ,NAME=SALARY ,$USER=TONY ,ACCESS=R ,RESTRICT=VALUE ,NAME=IDSEG, VALUE=DIVISION EQ 'WEST' ,$USER=MARY ,ACCESS=W ,RESTRICT=VALUE ,NAME=SALTEST, VALUE=INCREASE+SALARY GE SALARY,$ NAME=HISTTEST, VALUE=DIV NE ' ' AND DATE GT 0,$

Nate,



You could create your WHERE statement dynamicly. If you have a table that contains the relation between the user and his department you can do this very easy. Create a hold file that only holds the record or records valid for the user that logged in, by comparing the userid in the table with &IBIMR_user. Then use a -READ to store the department into a &var and
in your actual report you can simply code : WHERE department EQ '&var'.

Now if you have mulitple departments per user you could create a loop to contruct a OR phrase.


I don't know if you need this for every report or even a lot of reports? If so you could build a fex that does the above and run it every time the user runs a report. To do that just go to the Administration console under general there is a variable called _site_profile. Type: -INCLUDE FEXNAME\n . In this case I like to use a &&var to store the department(s).
We have done this before and works like a charm and most importantly there is almost non or zero effect on the performance of the report. That's the way we have done it If you're interested I probably can provide you some sample code and documentation on how we did it.

Hope this helps,