I need some advice - we currently run lid and ESS and MSS. Our employees log in to ESS using their nt login and passwords. They are all set up with user ids like seaemp seaempprq (for those using web reqs). Security for the class gives them access to all hr data.
We, the HR dept (among others) wants to implement portal so we can take advantage of design studio. Our IS folks are telling us we have a big security problem because if we use portal any one with an nt log in can browse to HR 11 and see everyone's data.
Seems wrong to me because I know other companies are using portal without this problem.
Can any one address this issue? I need some facts before I beginning challenging their perceptions.

No offense to your IT department, but that is completely untrue. Portal is very secure. In fact your data in Portal is just as secure if not more than it is in LID.

You tie your web user to an LAUA user through RD30 and viola they have all the security of the LAUA user. (not to mention some other access parameters)

Now you can go further and setup portal roles and muck with things as much as you like using some very simple custom code.

Additionally, using design studio you can hide certain fields and combine all types of fields while maintaining the same security.

So by all means, carry on with Portal. I personally think that especially on NT (and this is open for debate) that Portal is more secure than LID if you want it to be.

There is always the issue of encryption or lack there of but people forget that LID is just Telnet which is very vulnerable. And you can always implement SSL while you can't really use SSH with LID.

The issues that you will come across is with a user that is a Employee/Manager Self Service user AND will need Lawson access through Portal. For EMSS to work properly, the security class will indeed need access to the HR/PR/PA/BN data and some forms along with the other Lawson data access that that particular user/security class will need. This is with ENV 8.0.3 and below. 9.0 is supposed to have a better security model to fix this.

To get around this, these dual role/purpose users - one that need EMSS access AND other Lawson access will need to have 2 accounts. One account will be the Webuser that uses the generic LAUA user that ONLY has access to EMSS data and functions, and the Webuser account will use THEIR LAUA user account with a security class for ONLY the other LAWSON application/data accesses. How easily unsecure you will be will also be depend on if they still have access to the Search box and their knowledge of how to drill around in Lawson.

This is the only SAFE work around until you upgrade to 9.0 and the single signon security model.

mthedford is dead on.....in most cases you'll need two seperate logins as EMSS does require access to the HR applications to work correctly, and you might not want your portal users to have access to these HR forms. Until you upgrade to 9.0 to take advantage of the new Lawson security model, using two seperate logins is the easiest user implementation that your IT department can rollout to restrict access to Lawson forms. That's not to say that it's the only way, though.

One workaround does exist that will allow you to use one login for both EMSS and Portal. It's much more complicated to setup and maintain than two user logins...your IT department may not be willing or eager to set this up, nor would I blame them. However, there are some cases in which you may be required to use one employee-specific login for your applications. (SOX comes to mind). Workaround follows:

>>Allow laua access to the appropriate HR apps so that EMSS screens will work and assign user to that laua id in RD30. To address SOX concerns, I'd recommend giving the absolute minimum access required to this sec class to make the apps work and keep your auditors satisfied.
>>To enable this user to also use this same EMSS login with portal, create a modified .xml role and remove the portal search box. Remove access to the forms in your bookmark manager. In LX95.1, setup your webuser w/ the 'PORTALROLE' attribute to use the new modified .xml file. When they log in, they have no bookmarks or the search box to get to forms they shouldn't be in.
>> Even better, if you have Design Studio, create modified forms and remove functions and/or fields users don't need.
>Even mo' betta, use Design Studio to incorporate a bit of JavaScript on the back end of that form to either validate data or restrict data access based upon their user role.

And with this can of worms, I'm going fishing.

There are a lot of ways to tackle this issue (none of them very much fun):

1) Remove the search box from Portal. You should do this anyway because it is the biggest possible security threat that exists in Portal. The search box allows a user to type in HR11 and then HR11 will magically appear. Lawson has a good article on removing it: Article #68410.

2) Remove all form security from ESS users. They will only need access to a handful of forms in LAUA security HS10-15 (of which HR11 is not included).

3) Use HR security to restrict access to certain information for certain employees.

4) Use data security with criteria to restrict access to certain companies or departments data.

5) Customize the Portal bookmarks to only include access to the forms you want a user to have. Then make them required so they automatically appear and users don't have to add them themselves. Customizing your menu this way is a very powerful security tool and can be done in groups (example: HR can have one set of bookmarks, employee another, and managers another).

6) Use Design Studio to create your own secure forms.

7) Or don't do any of this and upgrade to 8.1 technology which claims to handle all of this more efficiently.

This gets expotentially more complex when you have some users that use LID, Employee self-service, requisition self-service, and manager self-service.

Hope this helps,

Aaron Frias
HRIS Analyst
Norman Regional Hospital
afrias@nrh-ok.com