LBI Security Groups VS Custom Groups

When it comes to security and access in LBI there are two schools of thought. The first is to build and maintain security with LBI security groups the second is to use the LS security classes and parameters to handle rights to data.

The questions that have come up as I have discussed this with others include:
1.) Is LS security set up with groups that make sense to give rights?
2.) Who maintains the rights to reports?
3.) Do you use attributes or user fields in rights management?

We have chosen to go down the path of using data, parameters, and security classes to build our rights. We do not maitain separate bursting rights or security groups in LBI. In discussions at CUE with several LBI experts, i think we are in the minority on this one but it works very well for our setup. We pull the username as a parm in many reports published on dashboards to limit data based on that user. We use attributes and user fields as data for VP, MGR, etc to burst reports on rather than set up rights in LBI. We have HR and Finance reps that keep these fields up to date for other reasons so we piggy back on that data. We have the AVAAP security dashboard product that also dumps our LDAP data into oracle tables that we use as data elements in reporting and bursting. We find it easier to include the data needed for bursting, rights, etc in the report than to maintain it elsewhere. The end results will get you to the same place.

The key to this decision in my mind is where do you want to do maintanence (security, attributes, etc or LBI) and who has the resources to handle it (IT or business areas).

I hope that helps

We use Lawson security to control access to LBI and drill around on report data. We use LBI report security groups to control access to reports. Our LBI rights are based on GL Accounting Unit and/or corresponding HR/PR department. e-mail me at joanna.bledsoe@jhsmh.org if you want to compare notes on LBI setup.

Report security groups work very well inside of LBI. For eg if you have a groupf of users who need access to a class of reports like financials you can create a security group called Financials and add all users who need access to the reports. When you publish financial reports instead of adding ids indiviually or LBI reoles you can add the security group.  For each report published the security group can be added which will restrict security at the report level. I have also found out that when you change security models or move from laua security to LS security when it comes to LBi the report security groups are most robust and migrate very efficiently.

However you cannot use report security groups for framework services or dashboard security.