Employee Self-Service under Lawson Security

John, the IOS.log will usually tell you what is secured so that you can keep adding the files/forms until you get it to works.  This is the method I took when setting up our new security classes.  I also would recommend securing the company and employee elements as well as securing each form that you open up to the individual employee or in the case of managers any employee that reports to them.  We ended up with two security classes (ESS, MSS) that we assigned to one role (SS) and assigned that role to the users.

This is an area I am disappointed with Lawson in, if they sell a client the ESS/MSS product they should include a security template with it.  There was talk one time of them doing that, have not heard if it is available,

I would talk to your account rep about this, see if there is something already built and ask them why it was not included with the product.  If enough clients do this they may rethink including it.

Then again with the shift in Lawson to the Employee Space and Landmark they may not care, but I think it is worth persuing.

When we implemented LSF9 security, for ESS, MSS and RSS, we started with the EmployeeRole.role.template, ManagerRole.role.template and the RSSRequester.role.template templates located in the $GENDIR/rnr directory.

It was not perfect but it was better than starting from scratch.

We had the same issue, although we've paired down our ESS menu options to 5-6 choices. Having to jump thru the same hoops, we gave access to 3-4 LS users, had them test all the menus so we could identify the tables that reported security violations, then had our security team grant access. Out last hurdle is in Org Chart. Org Chart hits the EMPLOYEE table to display some non-sensitive info on the employee. Internal Audit & Security have said non-management ESS cannot have access to EMPLOYEE...you never know when a user will figure out that they can build their own DME/AGS in a browser session and start looking at sensitive info (pay rates, etc). To satisfy IA & Security, we're replacing the EMPLOYEE call with a call to a custom table we've built that's a view of EMPLOYEE. The view will contain the same non-sensitive info that ESS is expecting to display.

We rarely call GSC for a number of reasons, the main one being that most of our Lawson code (COBOL, DS, html, etc) is customized and we already know what their response will be.

We attended the Security Administration class and were able to get templates for the employee and manager security. It wasn't perfect, but a place to start and better than what was delivered in the samples.

We used the fast track templates with some tweeks and have been running pretty well for almost a year now.

One recommendation that I got from Lawson was to install Fiddler which is a free tool that will trace your http requests.  When you get security violations, it is highlighted in red in fiddler and that enabled me to track down security requirements a little quicker.  hth.

Our solution here was to create 4 seperate classes (1 for housing the files for each ESS and MSS, and 1 for housing the forms for ESS and MSS and attached the appropriate class to either the ESS or MSS role. With the division of the classes it allows rules to be written thet do not interfer/over ride each other for those users who will have both MSS and ESS.  Also keep in mind if you have to edit the xml role to remove the search bar, for those users without the search bar there is no issue with the HR11, etc access, however we ran into an issuehere where a independent class for view only to sensitive info for our auditor and acct dept.....

We also used www.kinsey.com and fiddler app - this allows to see where the break in security maybe with x user or forms/tokens being accessed by x user if security needs to be tightened
In doing this it made it a lot easier on wrting the necessary rules...especially if HR11 field are to be tighented for those users who have the search box

For the supv - ensure the HR07 table is set correctly...the direct reports pulls form setup of there

Hope that your HR dept does not continually change their minds in what they want the emps to see and have the ability to process....

JB - BMH

The only significant constraint we had was with the ID.  We separated ESS functionality from Lawson application functionality (like AP or GL) with different IDs.  So some employees had two IDs.  Otherwise, we did not have an issue with ESS and security.  We added data file security, 1 security class, 4 roles and 1 Portal role.  The security class encomposed all of ESS.  The roles denied access to some bookmarks for certain employee groups.  The data file security only allowed access to their own data.  The Portal role removed the access to the search box.

All the tables used in ESS/MSS are defined in the HR.or file which is found in LAWDIR/PL/hrsrc directory. If you do a search on the the link name in ESS/MSS, you will find the information you need to secure any link in ESS/MSS. For example, say you want to limit the pay information for quarterly earnings available for a manager to view for someone he/she supervises. Do a search on "Earnings By Quarter" and you will find all the information you need to apply security to MSS. The HR folks decided the managers are not to see any of the infomation so, we created a rulle on the QUARTWAGE table to give access only if employee number in the EMPLOYEE identity matches the employee id in the QUARTWAGE file. Here is the rule we wrote:

if(user.getEmployeeId()==lztrim(table.EMPLOYEE))
'ALL_ACCESS,'
else
'NO_ACCESS,'

With MSS security you need to keep in mind that managers are also employees; therefore, you need to apply corresponding security to the HRFRMSSFiles security class and the HRFRESSFiles security class. In the case I have used above, both security classes would have the same rule applied to QUARTWAGE. The example I have used is straightforward which is the case for most of the security you need to apply. However, there are some exceptions and depending on what you use, you may or may not run into security you will need to be creative with.

Some Notes:

1. Links will not appear in MSS when it is secured as I identified above.

2. If you use LBI, you will need to apply the same security to any of the tables used to give file access to LBI users.

3. There is no way to apply this security to HR/PR managers without impacting there duties if their normal job performance requires full access to the files secured. We identified to HR/PR those managers who cannot be secured in MSS. Thankfully, HR/PR did not have a problem with these managers having access.

Sorry I'm late to this discussion. It seems that many of you have done a lot of work to secure ESS/MSS. This process makes it easier, but it is still work.

Jim

Does anyone know if there is a parameter we can use with install-rnr.pl that will let us load just one or a few of the templates and not all of them? Does anyone know if we take all the ones we dont want and move them to a sub-directory if the perl script will suffice with thats in plain sight of the target directory and not error on the sub-directory or try to traverse it? We only want to load the ESS and MSS stuff, not all the other bajillion templates. Any ideas? Thank in advance.

Carol

Just move them to a diff folder. =