slandess
Well Known Member
Re: Download File to Excel from batch Job
Scott: I disagree. I'm not trying to start a war here, but...
Edwards user > profile has to have "JDE" in the profile. In other words it
bypasses the AS/400 security > completely. JDE even recommends that you do
not use IBM Object level security.
JDE doesn't bypass AS/400 security. I think JDE utilizes AS/400 security in
a very convenient and consistent manner. They make JDE the owner of the
files and programs, sure, but I bet that other AS/400 software vendors
follow similar strategies. Have you ever worked on a system where user
authorities to EVERY object have to be maintained individually? If you have
not, it can be very difficult.
JDE make the assumption that you are going to secure the JDE users from
executing AS/400 commands by NOT giving them access to the command line
within the JDE menu system. I know of shops that don't even give the
programmers/developers command line access within the JDE menus. They
assume that you are going to secure your users from running programs that
they are not authorized to run by menu masking and security, NOT allowing
menu travel, and so on. JDE gives you a facility to allow users to execute
selected commands by defining those commands within CL programs and either
placing them on menus or defining them as hidden selections.
In summary, JDE has a layer of security that runs BELOW OS/400 security to
allow you a very flexible way of securing the JDE system. It is up to you
to define your security environment within the JDE framework.
Most JDE shops where I have worked also specify limited capabilities
LMTCPB(*YES) and INLMNU(*SIGNOFF) on the user profiles for most users to
prevent them from executing commands if somehow they are able to get a
command line, and also to prevent them from overriding their initial
program.
issues with ODBC > security. I can set up an ODBC Connection to our
Production Data lib. Set that
lib on
the
file from the
file.
You can write exit programs or buy a package like PentaSafe (no affiliation)
to maintain security to AS/400 applications like Client Access file
transfer, FTP, ODBC, and so on. Just like JDE security, you can secure
users from using these functionalities beyond the framework that YOU have
defined within your exit programs.
with *ALLOBJ >and some without).
I can't think of a reason for ANY user that can sign on to the system and
get a command line to have *ALLOBJ authority besides QSECOFR or maybe the
system administrator.
You might possibly have a profile used by a purchased or homegrown system
for backups or some other special purpose that has *ALLOBJ authority that
owns the programs for an application where the programs adopt the owner's
profile. In this case, the person who signs on to use this system should
not get a command line, rather be driven directly into an application that
controls what they can do.
JMHO
Steve Landess
V4R4 A7.3 cume9
EDI
(512) 423-0935
Scott: I disagree. I'm not trying to start a war here, but...
Edwards user > profile has to have "JDE" in the profile. In other words it
bypasses the AS/400 security > completely. JDE even recommends that you do
not use IBM Object level security.
JDE doesn't bypass AS/400 security. I think JDE utilizes AS/400 security in
a very convenient and consistent manner. They make JDE the owner of the
files and programs, sure, but I bet that other AS/400 software vendors
follow similar strategies. Have you ever worked on a system where user
authorities to EVERY object have to be maintained individually? If you have
not, it can be very difficult.
JDE make the assumption that you are going to secure the JDE users from
executing AS/400 commands by NOT giving them access to the command line
within the JDE menu system. I know of shops that don't even give the
programmers/developers command line access within the JDE menus. They
assume that you are going to secure your users from running programs that
they are not authorized to run by menu masking and security, NOT allowing
menu travel, and so on. JDE gives you a facility to allow users to execute
selected commands by defining those commands within CL programs and either
placing them on menus or defining them as hidden selections.
In summary, JDE has a layer of security that runs BELOW OS/400 security to
allow you a very flexible way of securing the JDE system. It is up to you
to define your security environment within the JDE framework.
Most JDE shops where I have worked also specify limited capabilities
LMTCPB(*YES) and INLMNU(*SIGNOFF) on the user profiles for most users to
prevent them from executing commands if somehow they are able to get a
command line, and also to prevent them from overriding their initial
program.
issues with ODBC > security. I can set up an ODBC Connection to our
Production Data lib. Set that
lib on
the
file from the
file.
You can write exit programs or buy a package like PentaSafe (no affiliation)
to maintain security to AS/400 applications like Client Access file
transfer, FTP, ODBC, and so on. Just like JDE security, you can secure
users from using these functionalities beyond the framework that YOU have
defined within your exit programs.
with *ALLOBJ >and some without).
I can't think of a reason for ANY user that can sign on to the system and
get a command line to have *ALLOBJ authority besides QSECOFR or maybe the
system administrator.
You might possibly have a profile used by a purchased or homegrown system
for backups or some other special purpose that has *ALLOBJ authority that
owns the programs for an application where the programs adopt the owner's
profile. In this case, the person who signs on to use this system should
not get a command line, rather be driven directly into an application that
controls what they can do.
JMHO
Steve Landess
V4R4 A7.3 cume9
EDI
(512) 423-0935
