ESS and Portal Security from 8.03 to 9.0

Answer to your first question: You need to use the 'mass assignment' feature in Lawson Security to assign the ESS users to a common OS identity.  See section "Sharing the OS Identity for ESS Users" in my article "Converting LID/Portal Users for LSF9" (https://www.danalytics.co...archive/2007-10.htm)

.

Thanks, John. We have the common OS identity defined in Priviledged Identities and assigned to the ESS users OS identity but the only way I can get around the LO secured errors is by assigning the common identity to the Admin security class in LAUA which I'm not thrilled about. Even when we have this set as such we're still getting errors within the ESS screens ie when executing a move life event: " 'undefined' is null or not and object". It appears that all the necessary users info is still not available for ESS to complete it's transaction request.

The answer to your second question is yes, kinda. You can do it with one OS identity, but as with 8.x, your LAUA security class would have to have access to the HR forms in order for that employee to have access to ESS functionality.

The common essuser definitely needs access to the LOGAN product line, LO systemcode / forms.

We got this working last night - things we changed were: Added the common essuser to the Lawson group in LAUA, added logan to all LAUA security classes and assigned the common essuser in the domain user field of the test ess user in Manage Identities. Oddly enough, I tested another new account this morning skipping the common ess user asignment in Manage Identities and ESS still worked fine. This makes me wonder if OS identity really need to contain the the common user id for "ESS only" users...

I may be misunderstanding what you're saying, but if you don't have an OSID for those users and you're using LAUA security, how can they have an assigned LAUA security class? Are you sure you're testing with security turned on?

The common user is defined in LAUA, assigned a security class and is assigned to the Lawson group. In my initial test, I assigned this common user to the ESS users "Domain_Users" field in Manage Identities. In a subsequest test for another ESS user I did not assign anything in Manage Identites and the user was sill able to log into ESS and retrieve their information. Lawsec is on and both ESS users Check LS flag is set to No in the RM record. Does this make sense?

Sorry - to clarify: the ESS test users are not defined in LAUA security, only the Common ESS user is - this scenario was part one of my original post.
The dual user (ESS and Apps) is defined in LAUA - this was part two of my original post.

I guess I didn't say that very clearly. What I meant was that you need to assign the ESS users to a common identity/OSID that is assigned to an LAUA security class.

Ok, I'm with you now.

So do we really don't need to assign the common user in the Manage Identities screen of lawsecadmin?

You do--you are assigning the common OS/LAUA user which has the security class (e.g., "essuser") to each ESS user, which doesn't have a security class or OS identity.

That's what's perplexing. On the second test account I created, I did not put the common webuser ID in the Domain User field of Manage Identities in lawsecadmin, but was sxtill able to log into ESS and pull up info just fine.

Do you have an ONLINE identity defined under privileged identities?  That would be used if the OS identity doesn't exist for an RM user...?

That expalins it - we don't need the domain login since the common account is assigned to online user in privileged identities.

Now for the dual users (Apps and ESS) that DO have a LAUA record and security class, will that take precedence over the security class assigned to the common account that is assigned to the online role in privileged iden?

For the dual users, they need to have an identity, which points them to an LAUA user/security class. The existence of that identity will override the ONLINE identity.

Thanks, that's what we want.

John,

Does the LAUA security settings for a user with their own OS identity set override the (online role) common ESS user access rights? We have dual mode (App / ESS) users that are "finance only" according to LAUA security and since moving to LSF9 it seems to be preventing them from accessing some of their ESS data in portal.

Thanks,

Joe

Yes. The ONLINE identity is only used if a user does not have an OS identity. You would need to update the LAUA security class for your finance users to include rights to the forms/tables needed for ESS. That may or may not be enough reason to start looking at Lawson 9.0 security. Some organizations also use dual IDs to deal with it.

Thanks for the update. On 8.03, our LID users security class was not enforced when they used Portal for ESS. We used dual ID's for the few Finance application users that used Portal to keep them out of HR. In 9.004 it seems that portal is enforcing the LAUA security class regardless of whether they are ESS only or App users.

what happens when you go to Lawson 10? We are on 9 and currently set up as well with an ONLINE privileged user that is tied to class in LAUA to get all the things they need for ESS, but in 10 LAUA no longer exists.

How does this set up work in 10 or does it anymore?

You create the privileged 'ONLINE' identity in Lawson 10 security administrator. It is an OS user that is used as a proxy for any user who is not assigned an environment identity. However, what a user can do and see is still governed by what roles are assigned to the actual user. For instance, if a user doesn't have a role that allows access to AP forms, just because a user doesn't have an identity, and is using the ONLINE identity, doesn't give them access to AP forms.

So really, all the privileged user is doing is allowing all the users to be without an environment identity? They dont inherit actual security once logged in? I know in 9 they inherited the security class etc that the privileged user had in LAUA.

So in 10 every user has to have their own roles? ....if that is the case, what would be the benefit of even having an ONLINE privileged user set up in version 10?

In v10 (or v9 with CHECKLS=YES), the online privileged identity is required in order to associate an RM user with an OS identity for GEN. Security roles from the RM user are required and used. Unlike v8 (or v9 when CHECKLS=NO), where an LAUA class is assigned to that user, there are no roles associated with the privileged identity.