Questions about the Lawson Delivered ESS Security Class -

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

alincoln

Basic Member

Posts: 12

10/3/2008 9:06 AM

Hello all,

We're a new Lawson deployment in the mist of setting up ESS and MSS for our employees.

Right now, we are trying to build our security classes based off of the Lawson delivered templates and I'm getting conflicting information on this method.

When attending a recent Lawson Security class (and in my Lawson System Foundation class) I was told that we should be using the Lawson delivered classes for our Self-Service security roles. However, I was told recently by Lawson Support that these classes are 5 (?) years old and they're not really supported anymore.

To further compound on this issue, I've found a critical issue with the Lawson Delivered ESS role. When a user is assigned to a role with that security class, if they navigate to HR11 and attempt to do a drill-around on the EMPLOYEE field, it crashes our environment with a "Failed to Fork OS Thread" error message.

Not to drift too far outside of the realm of security, further analysis of the JavaCore dumps show that during this time the number of active and waiting threads jump up to 150x the normal number of threads, thus the crash. I've reported this to Lawson and they're "looking" at it; but I'm getting the line "it's your security and we don't support that".

Anyway, I've removed the Search box from the ESS users role, but I'm not entirely sure how we'll address this issue with our ESS + Whatever employees (HR Staff, FI Staff, etc) since removing the search box really isn't an option.

Anyway, my questions:

1) Is it standard procedure to use the Lawson ESS/MSS/RSS whatever security classes for your Self-Service security?

2) Has anyone else seen the above issue with the standard ESS class and HR11? If so, how was it addressed?

3) If most shops are building their own security classes for the self service portals, what resources are available to help you figure out what access to set (in particular, the conditional access)?

Right now, we're sort of flying blind. CIBER is doing our implementation but getting them to help with security is like getting a political pundit to give a straight answer. Not impossible, but probably not worth the effort it would take.

Relevant info on the environment:

Platform: Windows/SQL
Environment: LSF 9.0.1
Security: LawSec
LDAP: MS ADAM w/ BIND to Active Directory

Thanks in advance for any help you can provide. Warning: I'll probably have questions about the answers too.

Rodney

Basic Member

Posts: 7

11/11/2008 2:13 PM

Hello...

We had the same issue with CIBER when we did our upgrade to LSF9 security. I feel your pain.

We just implemented ESS, and we used the Lawson delivered security classes for it...however, expect to fix their classes along the way because of missing screens/tables/rules/etc.

FYI - We did not receive the error on HR11.1 that you have above.

As for removing the search box, we went the route of having 2 different types of PortalRoles (a field in RM). We left default.xml alone and assign this to Lawson + ESS users. We then created a custom PortalRole called ess.xml that had the search box removed, this is being assigned to our ESS-only users.

Kwane McNeal

Veteran Member

Posts: 479

11/11/2008 2:28 PM

Those templates are definitley old, and were never completed for any use beyond those in the training manuals. Also if you are rolling out Lawson Security, you shouldn't be using those templates anyway, as they aren't appropriate in any mixed use cases, such as an Application user+ESS, or even MSS, and especially RSS+ESS

If you have any questions, feel free to call me.

Kwane
954.547.7210

PS: My qualifications are that I was one of the key people implementing this two years ago at a LARGE Healthcare client (second largest Lawson Security client, behind WalMart). We replaced just under 4000 LAUA classes, and the employee base was 12000 core users, and 285000 employees. I have also implemented every single piece at a few clients after that. So I have seen very odd situations, and may be able to help you.

Kwane McNeal

Veteran Member

Posts: 479

11/11/2008 2:37 PM

Also, to answer a few specific questions and points you raised:

1) "...Not to drift too far outside of the realm of security, further analysis of the JavaCore dumps show that during this time the number of active and waiting threads jump up to 150x the normal number of threads, thus the crash. I've reported this to Lawson and they're "looking" at it; but I'm getting the line "it's your security and we don't support that"...."

They are right. If you write rules incorrectly, and don't fully understand role cross-interaction, you could have a rule fire tens to nearly hundreds of times PER evaluation cycle. ESPECIALLY if you are looping through data (aka TABLE rules for drill)

2) "...If most shops are building their own security classes for the self service portals, what resources are available to help you figure out what access to set (in particular, the conditional access)?..."

Not much honestly. I wrote a ton of scripts to suck the data out of the Lawson metadata repositories to get me what I wanted. If you have understanding, it's not horribly hard, but keep in mind it took me almost a month to do it, though at that time no one else had done it, either at all, or on anything of the scale I had to figure this stuff out on.

Things like, how to I automagically take a rule for Batch Jobs, generate the correct screen field names, and mass load it all into the security repository, via lsload. Expect to end up with no less than 1100 unique security object rules on most large system codes. In that, you will have some overlap if you designed it right.

...Again, if you have any questions, feel free to call.

Kwane
954.547.7210

alincoln

Basic Member

Posts: 12

11/11/2008 3:02 PM

First, thank you for the responses.

I figured out why we were generating the JavaCore dumps with the default ESS security class, and it was a pretty "newb" thing:

The Lawson delivered ESS security class references an element group called "COMP_EMPLOYEE". Our deployment did not include a security class called COMP_EMPLOYEE. Nor can you create an element group with a "_" in it. I'm not sure how this got delivered this way, but obviously it's totally incorrect.

So I went back to the drawing board and created my own ESS class. I ended up using the Lawson delivered "Employee/Manager Self-Service Technical Documentation" to define the tables and programs that I needed to reference and wrote my conditional access around a new element group that simply recalls the users employee number from their identity.

This is combined with portal roles to suppress the search box (and indeed even the ability to add bookmarks; I'm simply locking the ESS/MSS bookmarks into their portal role via the locks tab) so I feel like our ESS/MSS deployment is now secure (and working).

So we've got something working now for ESS and MSS, but the on-going challenge is writing security for the rest of our HRIS deployment but that's a whole other topic entirely.

Rodney, if I could ask, who are you (or were you) working with at CIBER on your security deployment?

Rodney

Basic Member

Posts: 7

11/12/2008 6:25 PM

you can email me at rsheppard@edmc.edu and I'll let you know more....

C Fritz

Advanced Member

Posts: 19

6/16/2011 12:02 PM

I am hoping someone is still reading this thread. Can anyone please tell me the name of the ESS security class I should be looking for? I can not find anything in the list of installed classes that looks appropriate to the task nor can I find any documentation that I understand will install said security class. I have pages of classes, but nothing that looks like it goes with this set of applications. Thanks you in advance for your help.

alincoln

Basic Member

Posts: 12

6/16/2011 2:04 PM

You're in luck!

The default delivered security class with the 9.0.1.X deployment is just called "ESS" and "MSS" respectively. Please do keep in mind that they are for reference purposes only. Attempting to use them as is will probably cause your portal deployment to crash due to the broken element group they reference (not to mention they're horribly insecure).

The way we attacked ESS was to setup an element group for COMPANY-HR & EMPLOYEE and set the rule as:

if(user.getEmployeeID()==lztrim(EMPLOYEE))
then 'ALL_ACCESS"
else
'NO_ACCESS'

And then referenced the needed forms against that element group.

example:

if(isElementGrpAccessible(''.""."".lztrim(form.),lztrim(form.)))
''
else
'NO_ACCESS'

That is a great basic method of putting security around your ESS forms. You can use your employee heiarchy configuration to do MSS with the (user.isInChainOfCmdOfEmpInHR) method.

To determine what exactly screens you want to use, the Employee/Manager Self-Service Technical Documentation is pretty good about spelling it all out.

Good luck with your deployment!

C Fritz

Advanced Member

Posts: 19

6/17/2011 3:00 PM

Thank you! If it does not show up in the list of security classes - is there a place I can go to get instructions on how to make it show up?

I appreciate your information that the supplied class is broken. It will help manage my expectations. From all the prior postings, it does not appear this installation is an easily managed task for Lawson beginners.

BarbR

Veteran Member

Posts: 306

6/17/2011 3:10 PM

Our ESS security classes are EmployeeSSFile and HROREmpSelfServe.
Our MSS security classes are HRFRMSSFiles and HRORMgrSelfServe.
It's possible that these aren't delivered - we purchased FASTTRACK from Lawson to get our security setup quickly.

C Fritz

Advanced Member

Posts: 19

6/17/2011 3:16 PM

Thank you again. I will pass this on to my Director.

C Fritz

Advanced Member

Posts: 19

7/11/2011 12:41 PM

Here are two other questions.

1) If security classes ESS and EmployeeSSFile, etc are no where to be found, what is another, good, solid, out-of-every-box security class that one could start with, clone and prune that would get ESS working with minimal angst for someone with almost no Lawson experience .

2) On another thread there was a reference to a file in Lawson that I understood shows what each screen in ESS needs in terms of table access to work. I could not find that file on our system, either. Does anyone know alternative places for such a thing? I was hoping there was a one to one mapping some place that you could reference that would explain in very simple terms if you want this feature – say “Beneficiaries” to work you need to allow access to these tables and functions. Does such a thing exisit? And if so, where would you start looking for it.

John Henley

Posts: 3353

7/11/2011 1:40 PM

The Lawson-delivered roles are in $GENDIR/system/rnr/
They are installed by using the perl script $GENDIR/install/install-rnr.pl
The process for installing them is documented in the manual "Lawson Administration: Resources and Security" in the section "Installing Lawson-Delivered Role Templates".

As for the form security, consult the following resources:
"9.0.1.x Employee/Manager Self-Service Technical Documentation"
Document Number SHRRG-901UW-02

"Lawson Employee and Manager Self-Service Administration Guide"
Document Number SHRAG-901UWA-02

"Human Resources Form Security Supplement"
Document Number HRFSS-90UWA-03

Joe O'Toole

Veteran Member

Posts: 314

3/9/2016 8:50 PM

I know this is an old thread, but we are just starting to implement LS security in preparation for the eventual V10 upgrade and could benefit from some pointers.
Specifically, we are having trouble with EMSS bookmarks disappearing when we turn on CheckLS for users in our Basic AP security class.
We have installed the delivered EMSS roles but I'm thinking the access rules these afford do not fix for this sort of issue.
Without getting into complex form and field rules what high level items are required for EMSS to work alongside of LS security (data source. token, etc.)?

.

Greg Moeller

Veteran Member

Posts: 1498

3/9/2016 9:17 PM

At a minimum, you'll need to provide a security class with access to GEN data source, the CS category, and PROJECT and SYSTEM tables all within the GEN profile. Also, the following tables in LOGAN would be appropriate: CKPOINT, LOBKCONFIG, LOBKMARK, LOGRPBKMRK, LOPERSBKMK, LOUSRBKMRK, LOUSRBKOPT, some others possibly too.

Shane Jones

Veteran Member

Posts: 460

4/16/2016 11:15 AM

... when we rolled out LS security I don't remember having issues with bookmarks. I made very few tweaks to that role.

It sounds like you are saying emss bookmarks work until you add your ap class. If your emss works fine alone thenthen you must be specifically locking something in your ap class. Should be easy to review anything locked against Greg's list.

Joe O'Toole

Veteran Member

Posts: 314

4/18/2016 2:06 PM

Thanks for the tips. We worked on this with Infor support and it turned out to be an oversight on my part.
The security class to give access to Logan and the LO programs / tables was set up under the wrong profile PRD, we needed it in LGN.