RE: Row Security On Address Book....How about conditional column

[KBohn]

RE: Row Security On Address Book....How about conditional column

Hi everyone,

As there seems to be a lot of Security expertise at the moment, I thought I
would add to the question. Does anyone have a solution for the this?

We need to have conditional column level security for 'E' Search type
Address book records. In Canada, Social Insurance Numbers (Tax ID) & with
new legislation in 2003, employee address information is considered
confidential information. We have been running in Financials & Distrubution
for 2.5 years and are now implementing the HR module. Finance &
Distribution users require access to Address Book records (all information)
for Customers & Vendors & Employee records to pay expense reports etc. We
need only HR to have information to 'E' confidential fields though.

JDE says this can't be done in the application so their solution was a
custom ER modification on P01012 (A/B revisions) to hide those fields based
on user or group id. I did this & yes, that works for the Address Book
revisions application, but what about UTB? What about ODA? What about RDA?
Without actual JDE security setup, these security holes still exist. We
have users outside of the HR group who use ODA extensively to report on
financial data. We can't take that away from them, but there is nothing to
stop them from accessing F0101 (Address Book) or F0116 (Address by Date)
using ODA or UTB?

When evaluating the HR Module, we were assured that JDE Security was
extensive. This appears to be a huge oversight that JDE is not willing to
rectify. If I am missing a JDE solution, please educate me. Of course,
then there are the A/B reports, but that's another story.

Thanks very much,
Kimberley Bohn
QNX Software Systems Ltd., Canada
Xe, NT, SQL7.0, U5, SP17.1
WTS W2K

 

[CHo]

How about using row security on F0101 and F0116? Let HR group have access to Search Type of 'E' only. This will lock down UTB, RDA (file access), relevant applications and reports. I don't know about ODA.

Do you have row security set up? I'm in the process of setting up a sample row security for my report to management. It's a pain in the butt.

 

[cdawes]

Re: Row Security On Address Book....How about conditional column

Ahhhhhhhhh...it's been awhile since I've dabbled on the list (working for a
business partner = less free time)

I don't think that there are any permanent solutions but there are a few
work arounds. From the application end you can modify the address book to
achieve 'conditional' security. I've done this for a few HR/Payroll
implementations (Canada...eh?) and it works great from the application end.
The basic premise is that I have two identical custom menu trees identified
in the user profile except one is called G55HR (for Human Resources) and the
other is called G55FN (for Finance). I then insert logic into the address
book to hide or show certain fields based on the last two characters of a
users main menu. A new UDC indicates what field to hide or show and a
processing option determines what search types to hide or show for each menu
(G55HR or G55FN). This solves the application end.

As for the database end....well row security works on UTB and ODA and RDA so
you would have to have row security in place on search type 'E'. In my
solution I have no row security on search type 'E' since if I did workflow
wouldn't function for HR or any other module that used employees. My
solution is strictly at the application end. If you don't want people to
have access to a piece of information then try to following:
(1) Don't give them access to sensitive reports. Instead create or
modify reports NOT report versions since there really is no version security
in OneWorld
(2) Use column security on AN8, SSN, TAX, SAL, SEX, PGRD, PHRT, MSA,
DOB, JBCD, PDBA, GPAY, NPAY, GPA, SCUR, SHRT, PGRS, FAGE and PGSR. Column
security will work on ODA, RDA and maybe even UTB (check it!) and unlike row
security it won't cause you undue grief later on.
(3) If you have users who need access to ODA then use *ALL row security
on HMCU. HMCU or Home Business Unit is a field that is in every single
HR/Payroll table. MCU is the Financial Business Unit that is used to secure
Business Unit on the Finance side of things.
(4) Don't forget database security. You can remove the public grant on the
HR/Payroll tables (I can give you a list or you can get them from the KG).
Create a new RDB group called HRUSER and grant access to these table to this
group. Next proxy in the database password in JDE User Security for these
individuals only. This is the most secure way to look people out.

I've implemented all method (simultaneously) without any issues.

Colin Dawes
Sr. Technical Consultant, Syntax.net
B733.2- ERP 8.0, NT/2K and AS/400, SQL, Oracle 8i/9i, DB2
www.syntax.net



----- Original Message -----
From: "KBohn" <[email protected]>
To: <[email protected]>
Sent: Tuesday, November 12, 2002 9:49 AM
Subject: RE: Row Security On Address Book....How about conditional column


I
Distrubution
information)
based
RDA?
to



Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2

 

[KBohn]

RE: Row Security On Address Book....How about conditional column

Hi Colin,

I have changed the Address Book Application to hide the columns of
information based on user groups/user ids.

I have row security setup for users who don't need any access to 'E' search
type records at all, but we do have others (non HR) who need to see 'E's,
but they can't see the confidential fields such as Tax ID (Social Insurance
Number).

Column level security does not offer conditional based on search type. For
example, finance & distribution users need to see Tax ID for Customers &
Vendors, but can't see Tax ID for Employees. If you know how to do this
using column security, I would love to hear it. All I see for setting up
column security is:

User/System Role CORP_AP

Table Application Form Name Data Item View Add
Change Alias
F0101 TaxId N N N
TAX

I don't see how I would specify that for an A/P Clerk, they can see the
TaxId for 'V' (Vendors) Search type, but not for 'E' Employees. If I could
do this, I know that ODA, UTB & RDA should respect the security. I've been
told by JDE that there is no way to accomplish this.

Thanks for all the suggestions eh!!!
Cheers,

Kimberley Bohn
QNX Software Systems Ltd., Canada
Xe, NT, SQL7.0, SP17.1
WTS W2K

 

[cdawes]

Re: Row Security On Address Book....How about conditional column

Yes! That's exactly what I'm talking about conditional column security based
on search type is very possible with event rule logic in an application.
I'll dig out the code.

This does not however work at the database end for ODA or even for RDA since
this is custom logic. Sorry, but you're SOL here.

Some people take a quick work around and just create different roles for
differnt tasks or give a user multiple signon ID's, each with a different
purpose. Neither of these options are ideal but they do work.

Remember, you still have RDB level security to work with.

Colin


Colin Dawes
Sr. Technical Consultant, Syntax.net
B733.2- ERP 8.0, NT/2K and AS/400, SQL, Oracle 8i/9i, DB2


----- Original Message -----
From: "KBohn" <[email protected]>
To: <[email protected]>
Sent: Wednesday, November 13, 2002 9:12 PM
Subject: RE: Row Security On Address Book....How about conditional column


search
Insurance
For
could
been



Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2

 

[jean_driscoll]

It looks like it has been addressed by JDE. see ott-01-0089

 

[Amien]

Hi :
Is there any way-so that a user can see or access only one module (eg Human Resource Management).

 

[Amien]

how to make a role or a user accesses only to the application human resource management for example.

 

[DBohner-(db)]

Amien,

It is sSstrongly recommended that you partner with either one of the third-party Security Applications providers or with a consultant/contractor/trainer that knows E1 Security and can learn you the basics. A LOT CAN GO WRONG by activating the wrong policy.

Simple ways for security is by 'omission'. If you don't let users see menu items and you kill the FastPath - you eliminate the 'simple' users from touching other aspects of E1. After that, you secure them from specific 'launch' applications.

It's a daunting task - and one that I won't play... I'll stick to simple developer duties and remove most of the target from my shoulders.

(db)

 

[Amien]

DBohner-(db) :
Well, from what I read, this is not the application "P00950" that can personalized menu for a specific user.
If I am right, then how personalized it?

Best regards.

 

[peterbruce]

amien,

Maybe Disable multiple menus - Thread 116222 will help.

 

[jdel6654]

App security in combination with AB type versions of P01012 works.

 

[Harry Chen]

We have the same requirements for SIN # in address book. But I do not believe we can do it using purely JDE security. If ODA means other database access outside JDE of course it could not be controlled by JDE security.
For us we do not give users database access. They have to use JDE applications which can be controlled in customized event rules. JDE row security and column security all works well on JDE tools UTB, Databrowser.