Security Method

Hello list,

I need to implement OneWorld application Security for 3/4 of all OneWorld

modules, 75-100 security roles, about 2500 HTML users & 30-50 FAT clients.

I've had conflicting recommendations from JDE List & several consultants as

to the BEST approach to secure this environment. I NEED YOUR BEST TECHNICAL

RECOMMENDATIONS.


Basicly, there is 2 ways to approach this:


#1 PERMISSIVE APPLICATION ACCESS:

DESC: Restrict access to *PUBLIC for *ALL applications & GRANT application

access selectively via security roles.

PROS: Very secure. Impossible to access program without explicit program

access permission. Can leave fastpath access to users.

CONS: Extremely hard to maintain & setup. Need to make sure that ALL programs

necessary to users are listed in security roles. Very tedeous to setup since

need to consider all programs in users menu, programs called from within ERs,

Exit bars/menus and business fonctions. Their is no TOOL that let's me gather

a list of program dependencies (not even cross reference tool) to make sure

I,m not missing anything. Basicly, I need to test everything manually. Test

all procedures of all programs & make sure to note down all program names.

With hundreds of programs used by all users, this seems a DAUNTING task that

could take months with a very high risk of error. This option would also

generate a great number of records in the F00950 (Security workbench table)


#2 RESTRICTIVE APPLICATION ACCESS:

DESC: Leave access to ALL applications & restrict access to necessary

programs via menus & selective application restrictions applied to security

role.

PROS: Easy to setup & maintain. Minimum number of records in Security

workbench table.

CONS: Users can't have acces to Fastpath. Risk of HTML/FAT menu tampering

unknown. Can a user tamper (in any way) their HTML menus (edit HTML source

code of a menu page) to access unpermitted programs via the JAS server.



I am very tempded to implement option 2. Please let me know ASAP your views

on the subject.


================================
[email protected]
Senior CNC (PWC)

Michel,

Have you checked this issue in the archives on the XE Forums?
This issue have been discussed more times with many and valuable posts. Excuse me, I can not provide you currently the exact search phrases for the best search hits. I just want to notify you about check the archives. I hope you will find easy the best posts for you.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

Regarding your option 2, be aware that if a user can get a desktop they can reach any menu or run any application via a shortcut. LaunchUBE.exe can also be used to run any UBE.

If your users are all TSE users and they don't have access to a desktop. I know of at least two ways to get to a desk top unless your NT folks are alert.

In my opinion, the only real security is provided by your option 1 - deny all and grant access back to groups.

Dave.

David D. Helsley, Inc.
[email protected]
Xe, Unix Sp16.1, Oracle/MSSql, TSE

Michel,

Your analysis is accurate. In your situation, method 2 may be the only
viable means, as you conclude. It has some additional risks:

a) The access of programs via the row and form exits, which you are aware is
quite extensive. Example: Receipts Inquiry, P43214, has an exit to Reverse
Receipt. You can use Security Workbench to secure the exits, but that is a
lot of work also.

b) From the main menu, if one does File, Open, one gets the Menu Select
screen and one can go to any menu. Hmmmm.

Solutions: I know of none except your method 1.

Dave Mallory Denver Water

All users using the FAT desktop will be administrative users (about 30) . A lockdown of all objects could be applied to the roles used for those FAT client users. This would be more manageable since it concerns a limited number of users & apps & not applied to *PUBLIC.

Would their be any risk implementing option 2 for the HTML users??

================================
[email protected]
Senior CNC (PWC)

Michel,

as Zoltan stated this topic has been discussed before - search the forum archives.

That said I take issue with part of the the CONS statement for option #1. Specifically "Extremely hard to maintain & setup."
While initial setup can be tedious for this option,the maintenance of the approach is actually much lighter than that required for #2. If you search the archives you'll see why

A common hole in people's thinking about JDE security is that securing access can be accomplished via restrictive menus, securing FastPath, etc. What is forgotten is the Row and Form Exits within applications themselves. It is amazing how far you can wander within the system just by jumping from application to application using form/row exits.

Net, net David's statement "In my opinion, the only real security is provided by your option 1 - deny all and grant access back to groups." is correct. What you have to decide is how serious your organization is about security.

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials

We are going to go with method 2 here. The reason being we are using task
menus and can lock down the users to just what they need to see. They don't
want massive security to maintain. The users will have no fastpath either.
They are now looking at what programs are critical that they need to lock
down. We'll also have extensive row and column security in payroll/HR.
We'll use row security to lock up Business Unit, search type, etc... UDCs
and setup options will be maintained only by IT Business Analysts, not
users. We'll also be doing some exit and tab security where necessary.
This sounds like a lot but it will be less effort up front and less problems
at go-live time than if we completely lock it down and then hear mad cries
from the masses after we go-live....

Hey, I'm also setting up Inclusive Row Security instead of Exclusive--anyone
using that? (new with SP16)



Lori
OW Xe SP16 Update 2
AS400 V4R5
NT
Citrix
email: [email protected]

Michel,

I just wanted to mention that we faced the same question about security.
We opted for your #1. This was a lot of up-front work for our security
officer, but in the long run, we know that our applications are secure without
having the threat of someone being curious and exploring where they shouldn't
be. We also removed fast path access.

With #2, you will be constantly monitoring your users, making security an
every day task.

We enlisted our functional team members to make the initial set up requests
by looking at each application they use, then doing the actual testing of
the security.

We have approximately 150 fat client users and 100 citrix users. It took
our security office approx. 6-8 weeks to get everything ready for go-live.
We did some fine-tuning on a regular basis for about 3 weeks after go live.
But, things are definetly coming together now.

Hope this helps,
Mechele
CNC Consultant
Xe, SP16, Update 1
Unix/AIX, Oracle
Fat/Thin Citrix Users

-- Original Message --

since
gather
sure
Test





Visit iWon.com - the Internet's largest guaranteed cash giveaway! Click
here now for your "Thank You" gift:
http://www.iwon.com/giftcenter/0,2612,,00.html?t_id=20157





Mechele Baker
Xe, SP16, Unix/Aix, Oracle 8.1.6
Citrix, Fat clients

Re: RE: Security Method

The "menu select" screen is application P00820. Should be able to secure it like any other.

Dave.

David D. Helsley, Inc.
[email protected]
Xe, Unix Sp16.1, Oracle/MSSql, TSE