User Security

[ToddT]

I have been asked to open up user security to the managers over specific application areas (i.e. HR, Payroll, A/R, etc.). The managers want the authority to add, modify, and remove users from within OneWorld Xe. They also want to be able to add groups and modify the application security for those groups.

My question is, how could this be accomplished while preventing them from accessing users from other application groups and tracking what they have done just in case they mess up?

We are running OneWorld Xe on an AS/400 and we considered utilizing the AS/400 journaling. The problem being a new journal entry would be created each time there is access to the F0092 and F00950, we would end up taking a performance hit. We performed a test against the F0092 and that alone provided a performance hit.

Any assistance any of you could provide would be greatly appreciated.

 

[lessardj]

At FOCUS, Lorna Cordeiro and Todd Tuffs from Shell Canada gave an excellent
session on this subject. They created a user-friendly copy of the security
application and gave it to power users. This application ran over a copy of
the F00950 file. Once a day (or periodically) the Admin would run a
comparison report between the copied version and the real version of the
security file, then sync it up, if they saw no problems.

They did not include the user profile application in this discussion.

The handout should be on the Quest web site, if you have access to it. The
session was "Simplifying OneWorld Security Administration."



Xe, SP 17.1_E1, Update 2, ES=AS/400 V5R1, CO=AS/400, Thick & Citrix Clients

 

[DSauve]

Todd,

I think that the managers are making a dangerous request, and that they probably don't fully understand what it is they are asking for. Security should be centrally controlled so that you don't end up with different groups changing security, possibly on each other's users. Even if you used some sort of row security, I don't think you could secure the Security Workbench adequately, especially if you allow them to add new groups (besides changing existing groups).

Functional area managers are responsible for the business data in their respective areas, and they should be the ones to define security requirements for their users, but it is my opinion that these requirements need to be directed to a Sys Admin/Security person for actual implementation. Otherwise, I think you're opening up a nasty can of worms you will regret for a LONG time.

 

[gerd_renz3]

Todd,
I completely agree with Don´s answer.
As a consultant I have participated in many implementations. I have never
seen managers to handle security issues. They should be given all access
they need. But they should be granted this access by the technical
personal, not taking it themselves.

Thanks, Gerd

 

[sperkins]

Hi Todd

Don Sauve has given you the best advice. I looked at this for a client
where the accountants were clamouring for control of security, with,
according to them, some justification.

The dangers and risks are huge, again as Don points out. Because no
reasonable argument was being accepted I asked JDE UK to offer some
arbitration on the subject.

Their recommendation? Users to define their security requirements and
CNC/Security to implement. It's the only safe option. Journalling does
help track events but comes with a performance overhead, and, it is a bit
like shutting the door once the horse has bolted. Security must be in the
hands of a trained and trusted professional.

I therefore suggest you go with Don's advice, and JDE UK's too I guess, and
persuade your colleagues to accept your greater understanding of these
matters when it comes to OW. It won't be easy and I wish you luck.


Sid Perkins
Independent JDE Consultant
[email protected]

Tel: +44 1304 825003
Mobile: 07713158807

----- Original Message -----
From: "ToddT" <[email protected]>
To: <[email protected]>
Sent: 25 June 2002 15:04
Subject: User Security


application areas (i.e. HR, Payroll, A/R, etc.). The managers want the
authority to add, modify, and remove users from within OneWorld Xe. They
also want to be able to add groups and modify the application security for
those groups.My question is, how could this be accomplished while preventing
them from accessing users from other application groups and tracking what
they have done just in case they mess up?We are running OneWorld Xe on an
AS/400 and we considered utilizing the AS/400 journaling. The problem being
a new journal entry would be created each time there is access to the F0092
and F00950, we would end up taking a performance hit. We performed a test
against the F0092 and that alone provided a performance hit.Any assistance
any of you could provide would be greatly appreciated.

 

[david_mallory]

I agree with Don Sauve. The managers need to get real and acknowledge that they are saying "there should be no control." THEY would regret this in 6 months. You would have chaos. One or two people (we have 2: me as auditor and the I.T. person) should control security: adding/deleting users and user groups, controlling access by user group by program, etc. Very bad idea they have put forth. Soon they would be pointing fingers at each other.

 

[davids]

If anyone can get their hands on this doc, how about sharing
it with the peanut gallery ;=) ?

 

[LoriStephens]

Todd,

No way would I let any managers get into security--or anyone for that
matter. (We control it in the CNC area here for user entry and we have a BA
managing the security workbench for application security and I do the
technical security.) They have their own areas to worry about and security
should be centralized. You could put some sort of row security if you allow
them to touch certain groups but sheesh! what a mess they could create!!
Learn to just say NO...

You need a good CIO to say NO for you...




My question is, how could this be accomplished while preventing them from
accessing users from other application groups and tracking what they have
done just in case they mess up?

We are running OneWorld Xe on an AS/400 and we considered utilizing the
AS/400 journaling. The problem being a new journal entry would be created
each time there is access to the F0092 and F00950, we would end up taking a
performance hit. We performed a test against the F0092 and that alone
provided a performance hit.

Any assistance any of you could provide would be greatly appreciated.




Lori
OW Xe SP19 Update 5
AS400 V5R1 NT
Citrix
email: [email protected]

 

[cdawes8]

Todd,

Anything is possible in OneWorld the question is do you really want to do
this?

The FOCUS session on "Simplifying OneWorld Security Administration." was
more likely "Distributed OneWorld Security Administration" since the
simplification really came from having non-CNC/Sys Admin do the
configuration and then having the CNC/Sys Admin 'promote' the changes.

If this what you're looking for then you can find all FOCUS presentations
are on the Quest Web Site (www.questdirect.org). If you go into Members then
'Education Archives' you'll find all the presentations. If you don't have a
Quest login get one or find someone that has one (or just advertise and I'm
sure some generous person will find the doc and send it to you).

You'll really want to examine whether you want centralized or de-centralized
security. Many factors come into play.....ie for centralized it can be a lot
of work for the CNC/Sys Admin whereas for decentralized you'll need to train
Mangers to use the security tools.

We use a combination of centralized & decentralized. All *PUBLIC & GROUP
level security is centralized whereas USER level security is decentralized.
USER level security is restricted to Finance Business Units (MCU), Finance
Companies (CO) and HR Business Unit Security (HMCU).

Colin

B733.2 SP17.1_I1
Intel/NT/2K/Oracle 8.1.7.1

 

[CHo]

During one of the FOCUS sessions, Security the Next Foundation, for ERP 9.0 the security workbench has been simplied so that business analysts (power users) can use it especially when the system is being set up for the first time.