• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

OW Xe Security - *PUBLIC (ON or OFF)?

Graham_Aberdein1

Active Member
Hi List,

I know this is not a black or white question, but we are implementing OWXe
and would like to hear from others on whether they turn *PUBLIC on or off.

We have generally heard/been told that *PUBLIC turned ON is less security
setup work/more risk and *PUBLIC turned OFF is more security setup
work/less risk. What we're struggling with is quantifying both the
workeffort and the risk.

Thanks in advance for your help.

Graham
 

Zoltan_Gyimesi

Legendary Poster
Hi Graham,

Although I amn't a CNC guy or security administrator, just a developer, let me tell my opinion.

First make clear:
*PUBLIC turned ON means: enabled
*PUBLIC turned OFF means: disabled
Am I right? Do I understand you right?

If the answers are yes:

If you require a strict security (at least medium) then *PUBLIC turned ON could easily result in (much?) more security setup than *PUBLIC turned OFF, as more strict as more setup.

In my honest opinion, *PUBLIC turned OFF way is the better, safer, more magageable, approach.

Zoltán


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

Larry_Jones

Legendary Poster
Graham,

We use the *Public approach here. We watch our access very closely so we chose to secure everyone out and give them back what they need. It seemed like a lot of work in the beginning, but it has paid off. We don't have to worry about someone getting into something they shouldn't.

Don't think you can control access solely via user specific menus. Form and Row exits inside of programs by-pass this method of security. You can go from program to program to program using this method.

Security was a full-time job for a month or so but after that period it became just another one of the admin duties.

My 2 cents.



Larry Jones
ljones@wagstaff.com
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials<P ID="edit"><FONT SIZE=-1>Edited by Larry_Jones on 8/23/01 10:51 AM.</FONT></P>
 

fat_elvis

Member
I agree with Larry, "inclusive" compared to "exclusive" security is by far easier to manage and track in the long run. Think about it, you first have to identify what access your users require before you can do any security mapping. Now I'm assuming that most sites overall determine what users need rather than what they don't need with this approach.

If you apply the inclusive method (*PUBLIC = *ALL) you only have to grant those permissions (that are now identified) and you're done. If you miss anything, chances are your users will let you know, in which case you simply add it (obviously only if they're required to have it). Point is, you're aware of what access has been given and for what reason.

With exclusive security, you must now identify everything that ISN'T on that list and revoke it. Remember that in addition to Hyper Exit (Row & Form) you also have Tab security. And, if Fast Path is enabled for users, obscure objects not on menus can be invoked - and these are typically either obsolete or worse, administrative programs. Let's face it, there's stuff in OneWorld that's not clearly visible. With exclusive security, I can't guarantee I'll find it before an end user does.

It is more work in setting inclusive security up, considering that each user has their own unique security requirements, but like Larry mentioned, the benefit of knowing that users can't wander where they shouldn't is worth it.

OneWorld Xe SP15_010 - AS/400 V4R5 - Central Objects on AS/400
 
RE: Re: OW Xe Security - *PUBLIC (ON or OFF)?

--openmail-part-3fae33fa-00000002
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline; filename="BDY.RTF"
;Creation-Date="Thu, 23 Aug 2001 17:12:24 -0500"
Content-Transfer-Encoding: quoted-printable

We will use public =3D off and turn on required use as needed.

Christine Pouliot
GFS - Global Financial Systems #59
Worldwide Product Manager
JDEdwards A/P, A/R, A/B, Interco & Treasury
952-984-1127 (phone)
952-404-6033 (fax)
x-855-41127 (rnet)
christine=5Fpouliot@cargill.com



=2D----Original Message-----
From: zoltan.gyimesi@Synergon.hu [mailto:zoltan.gyimesi@Synergon.hu]
Sent: Thursday, August 23, 2001 12:45 PM
To: jdelistml@jdelist.com
Subject: Re: OW Xe Security - *PUBLIC (ON or OFF)=3F


Hi Graham,

Although I amn't a CNC guy or security administrator, just a developer,
let me tell my opinion.

First make clear:=20
*PUBLIC turned ON means: enabled
*PUBLIC turned OFF means: disabled
Am I right=3F Do I understand you right=3F

If the answers are yes:

If you require a strict security (at least medium) then *PUBLIC turned
ON could easily result in (much=3F) more security setup than *PUBLIC
turned OFF, as more strict as more setup.

In my honest opinion, *PUBLIC turned OFF way is the better, safer, more
magageable, approach.

Zoltan


B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
=2D-------------------------
Visit the forum to view this thread at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl=3FCat=3D&Board=3DO=
W&Numb
er=3D19589=20
 

Carl_Fisher

Well Known Member
I agree - from the point of

OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
 

lessardj

Well Known Member
When taking the *Public approach, do you then need to create security for
JDE to access to all?



Xe, SP 15.1, Update 2, ES=AS/400 V4R5, CO=AS/400, Deployment=AS/400 INS Card, Thick & Citrix Clients
 

Jack_Crouch

Well Known Member
If we had it to do over again... I would recommend that the *PUBLIC not be
allowed to anything. The pain would have been worse. But we would have
been in a happier and more secure space than where we are now (migrating
over to a *PUBLIC not allowed setting).

I had a gut feeling about that... but did not go with it. Just didn't know
enough about it at the time.





AS400 V4R5, XE+XU1+35ESUs, SP16, NT-SQL7 for CO
 

kastanek

Well Known Member
Hi Graham,

Typically when I set up security I do it during the CRP phase of an
implementation so that it can be tested by the core team and fine tuned
before go live.

Also I've found it best to have security in place during testing so that
the end-users do not see lots of stuff during training and then feel
targeted when they get only a few menus at go-live although your appl.
consultants may feel differently.

During CRP you should set up the user groups that you will need and grant
them the appropriate security so that they can do their jobs.

Grant JDE and any admins you have Appl=*all Security= *all so they can get
into anything.

When you feel that you have the correct security in place for your groups
you can turn Security OFF for *Public. This is actually less time
consuming. Think about it. If you have 20 programs across 6 modules and
you want a user to have just one module... is it easier to grant them
access to one module? Or to deny them access to 5? There are less security
records when you grant groups what they need and turn *public off. Also,
less security records means faster menu navigation and performance in that
respect.

Beware! When you turn off *Public security there are certain things
that need to be turned back on... such as Printer Selection, Password
change capability, UBE selection, Version Selection, etc... otherwise
people can get into their application but none of the basic system
functions like selecting Versions and submitting jobs. I have a list of
about 76 programs that I give access back to *Public for. It's fairly
complete but with each new release I find more.

I hope this helps.

Regards,
Gerald.







Graham.Aberdein@c
larica.com To: jdelistml@jdelist.com
Sent by: cc:
owner-jdelistml@j Subject: OW Xe Security - *PUBLIC (ON or OFF)?
delist.com


08/24/2001 12:15
AM
Please respond to
jdelist





Hi List,

I know this is not a black or white question, but we are
implementing OWXe
and would like to hear from others on whether they turn
*PUBLIC on or off.

We have generally heard/been told that *PUBLIC turned ON
is less security
setup work/more risk and *PUBLIC turned OFF is more
security setup
work/less risk. What we're struggling with is
quantifying both the
workeffort and the risk.

Thanks in advance for your help.

Graham





--------------------------
 

kastanek

Well Known Member
One more thought Graham,

I was wondering why you would have been told that *Public = ON is less
work. It depends on how much work you plan to do with Custom menus and
Fastpath authority.

If you are going to create custom menus for everyone then *Public ON might
beless security work but lots more menu work and fastpath has to be turned
off.

If you take my suggestion of granting authority to the groups and turning
*Public OFF then you can use the OW default menus and turn Fastpath on for
end users.

Regards,
G.





Graham.Aberdein@c
larica.com To: jdelistml@jdelist.com
Sent by: cc:
owner-jdelistml@j Subject: OW Xe Security - *PUBLIC (ON or OFF)?
delist.com


08/24/2001 12:15
AM
Please respond to
jdelist





Hi List,

I know this is not a black or white question, but we are
implementing OWXe
and would like to hear from others on whether they turn
*PUBLIC on or off.

We have generally heard/been told that *PUBLIC turned ON
is less security
setup work/more risk and *PUBLIC turned OFF is more
security setup
work/less risk. What we're struggling with is
quantifying both the
workeffort and the risk.

Thanks in advance for your help.

Graham





--------------------------
 

boaterdan

Active Member
I think what is meant is that it's less work assuming you want a very open/sloppy security model. To take it to an extreme, if everyone is allowed to do everything and you just trust that they won't, you really don't have to enter anything.

From a theoretical standpoint (and it applies to the network, internet, OS) you always end up with more control and confidence in the restrictions when you remove all rights and grant back as needed.

My System Admin trainer put it this way - if a user finds they can't perform some function critical to their job, you can rest assured they'll tell you, but if a user finds they can do something they're not supposed to be able to, you may or may not ever hear about it.

---------------------------------
OneWorld Xe SP15
Clustered Windows 2000 + SQL 2000
 

david_mallory

Well Known Member
We turned *PUBLIC off and grant access by user group by program, and thus
those things granted are all they can run. I would do it the same way again.
The trickiest part was finding the programs that get called here and there
by the program you are running. For example, AP voucher program P0411 calls
P4314 voucher match but you do not see P4314 on any menu. It took about two
weeks to find 98% of them in test and add them to Security Workbench, and
the rest we fixed when the users said "I can't do ......".

Dave Mallory Denver Water
 

TWPattiR

Member
You said you have a list of about 76 programs that need to be turned back on when *Public is OFF - would you be willing to share that list? I am working on implementing "closed unless open" security in our Xe upgrade testing, and would appreciate any assistance I can get to make this a smooth transition.
Thank you in advance,
Patti
 

LoriStephens

Well Known Member
I would like a copy of that list also... of the 76 programs that need to be
turned back on when *public is off... I am setting up security by groups
but will still need this for the groups that I turn off everything in...

Thank you!!

:)

Lori
OW Xe SP16 Update 2
AS400 V4R5
NT
Citrix
email: jdeperson@hotmail.com
 

jde_cnc

Active Member
Count me in, as well. I would greatly appreciate a breakout of the required "grant-back" programs that are needed for basic functionality.

Please post to download section if possible or email to jde_cnc@hotmail.com.

Many thanks in advance.

OneWorld Xe SP 15.1, Update 2
Win2K Advanced Server/SQL 2000 Enterprise Edition
Metaframe 1.8, NFuse 1.51
 

david_mallory

Well Known Member
If you go to the JDEList web site, Downloads, and see "Security Settings by
Program and User Groups Spreadsheet", that is the security setup we have,
for the GL, AP, FA, JC, purchasing, and inventory modules. We found doing it
this way was workable, although quite a bit more work, and we like the
results.

Dave Mallory Denver Water
 
Top