PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 04/18/2016 10:06 AM by  Joe O'Toole
Questions about the Lawson Delivered ESS Security Class
 16 Replies
Sort:
You are not authorized to post a reply.
Page 1 of 41234 > >>
Author Messages
alincoln
Private
Private
Basic Member
(26 points)
Basic Member
Posts:12


Send Message:

--
10/03/2008 5: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
    Private
    Private
    Basic Member
    (19 points)
    Basic Member
    Posts:7


    Send Message:

    --
    11/11/2008 9:13 AM
    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
    Private
    Private
    Veteran Member
    (1299 points)
    Veteran Member
    Posts:433


    Send Message:

    --
    11/11/2008 9:28 AM
    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
    Private
    Private
    Veteran Member
    (1299 points)
    Veteran Member
    Posts:433


    Send Message:

    --
    11/11/2008 9:37 AM
    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
    Private
    Private
    Basic Member
    (26 points)
    Basic Member
    Posts:12


    Send Message:

    --
    11/11/2008 10:02 AM
    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?
    You are not authorized to post a reply.
    Page 1 of 41234 > >>