Security Issue

[GSI Inc.]

Hi all, I am implementing security in Enterprise One. What we have now is not public exclude and then granting by object. But this is what we have to go to for a SOX requirement. The problem I am having is identifying all the objects that a user may need. For instance you can't go to the x-ref file and find all the UBEs(reports) that are submitted via the Payroll Workbench. What I have done is build a file from the menus of all access they current have to forms and UBEs. The problem is there is nothing showing in the xref files what UBEs are called from forms or what ube's are called in a submitted job stream such as the R07200 which once it starts running on a server submits more jobs. What I have had to do is setup a test group and user that the first security entry is application security that states that that group can't run any application. Then I adding entries based on their current menus. Then I have to test it by signing on to that test user and submit a job(s) and look in the employee workcenter for errors on jobs that do not have authority. Very time consuming. I have about 40 unique groups setup that I would have to have a test user for each one and sign on and find out what authority they do not have and then add and entry to the security table for run "Y".

I know some consulting firms have a list of possible UBE(s) and forms by system code that may be used. Also I belive this is how it is done with the 3rd party software from Qsoft(sp). Any ideas or insights would be greatly appreciated and I would name my next child after you. Well maybe not that. But It would wonderful for any insight as JDE support has not helped at all.

Thanks, DetroitBobby - Shake it easy

 

[custhe]

Bob,
Hopefully someone can offer a better way, but I just went thru the same thing in December the hard way. As far as batch jobs go, I gave myself a headstart by interrogating the submitted jobs file, to see who has been running what jobs (regardless it it was called from a menu, or spawned from other jobs). Fortunately, my user community is not very disciplined at deleting out their submitted jobs. On the IV side, I just sucked it up, walked thru every screen on our menu, kept burrowing into row exits as I went, making decisions along the way. Maybe not the best thing for me to make the initial decisions, but I did have key user groups test after I set up the security, and sign off on the setup (to be used as a baseline for SOX).

For what it's worth, in order to simulate the security layers,
I created a group *TPUBLIC, laid in security here of what would eventually become *PUBLIC (e.g. App N/N, Action NNNYNN)
Then I created test Users (TBUYER, TQUALITY, etc) as members of the *TPUBLIC group, to simulate what would eventually become the respective group security (*BUYER, *QUALITY).
This approach kept the original wide open *PUBLIC records from coming into play while I was testing.

Then when I was ready to go live with the deny all / grant back scheme, just did a bunch of security "copy and replace" operations to move the security from Test Users to Groups, from Group to Public.

 

[andymcclure]

Bobby,

What release are you on? I have found that with 8.9 and higher the xref
file does have a list of applicaitons (including UBE's) that are called from
another application. I have created several reports that enabled me to view
see what applications are called from the row/form exits, and if the role
has access to those applicaitons.

I have worked with the Qsoftware product, and while it is a great product, I
do not feal that is needed if you using 8.9 or higher.

Andy

 

[GSI Inc.]

Re: RE: Security Issue

I am currently on XE. We have not moved to the new upgrade because of the extended support of XE. Because of SOX requirements we have to go with *public exlucde before we upgrade. I wanted to upgrade this year but I am the only, analyst/programmer/security specialist/business analyst on staff. So upgrading became impossible this year because of other priorities; but the new security model must be in soon because of dear old SOX.

I have just got to believe there is someone out there that has a list of commune UBEs for payroll that need to be setup.

Thanks for your help, Bobby