Durbin_Black
Member
All-
We are running OneWorld on an AS/400, release B733, SP 11.3. We would like to
roll out OneWorld to a large population of people to use for real-time financial
inquiries, purchase order inquiries, work orders, reporting, etc. We're having
some trouble putting together a security model to accommodate this.
Here is how the security needs to work:
A user belongs to a division and cannot see information associated with other
divisions.
A division is a business unit category code (BU CC #1, to be exact), and
therefore is a collection of business units.
We have about 1200 business units, so each individual would have access to
information for about 50 BUs while being excluded from information associated
with the other 1150 BUs.
Here are the ideas we've rejected so far, and the downsides to each:
1) Row security - each division in the company would be setup as a security
group. Each user would belong to one of these groups. That group excludes,
through the use of row security, every business unit not associated with that
division. Essentially, for every security group (division) there would be ~1150
lines of row security. Two problems with this: 1) Performance - it seems like
1150 lines of security for 20 different groups (divisions) would create a
performance hit for the system. Can anyone give a general idea of what this hit
might be like? 2) Maintenance - whenever we have a business unit move from one
division to another we would have to modify every security group, and frequently
we move more than one business unit at a time (10 or more). One potential
solution to the maintenance problem is having a UBE that runs nightly to update
the security records based on any changes in the cost center master (or we could
do it with an RPG program since we're on a 400). Our main concern with this
solution is the performance hit.
2) Security built into individual applications - We could modify applications to
look at the user ID before performing a fetch, locate the user's address book
record, find out which business unit they belong to, determine the division
associated with that BU, and then execute or do not allow the fetch based on
that information. There are a lot of problems with this solution: 1) There are
quite a few inquiries that we would like to give people and this would require
modification of each. 2) There are even more UBEs that people would have
access to, and I guess this would require modifying each of those also. 3)
Every time there is an update/new release for OneWorld our modified applications
and UBEs would get overwritten and would need to be modified again. (Unless we
made copies and kept them in one of the protected systems [55-59], but then
we've still got to create new copies based on the new inquiries if we want to
take advantage of any of the new features in the new release.) 4) Every time
we want the general population to get something new, we've got to modify it to
accommodate security.
3) Adding business unit category code 1 (division) to each business view that
might be fetched against by a user - This is essentially the same as option #2,
except instead of modifying the applications we would be modifying the business
views that those applications use. The general idea is that if we can add BU
cat code 1 (division) to all of those BSVW's then we should be able to secure by
division directly instead of having to secure by business unit to simulate
securing by division. We would still have to add row security for each
division, but it would only exclude 19 or 20 divisions instead of 1100 business
units. The same downsides apply here as apply to #2: 1) There are a lot of
BSVW's that would need to be modified. 2) Those modifications would be
overwritten at each new release.
4) Table Event Rules - At one time we spoke with a JDE representative and they
suggested that we add TER to each table that would perform a security check when
the table is fetched against. Subsequent research has turned up a problem: you
can't stop a fetch through TER even if you find out the user isn't qualified for
the information that they're fetching. The best you can do is clear the fields
on the returning dataset which doesn't seem to be a very desirable solution (and
actually seems potentially dangerous). Does anyone know where to access a fetch
through the C-code to cancel it or whether this might be an option (write a C
business function that's called from TER)?
If anyone has any suggestions about a good approach to securing by a business
unit category code I would greatly appreciate hearing from you. If I have
rejected one of the above ideas out of hand, please let me know if you think
they might be an acceptable solution.
Thanks for your help!
Durbin Black
International SEMATECH
We are running OneWorld on an AS/400, release B733, SP 11.3. We would like to
roll out OneWorld to a large population of people to use for real-time financial
inquiries, purchase order inquiries, work orders, reporting, etc. We're having
some trouble putting together a security model to accommodate this.
Here is how the security needs to work:
A user belongs to a division and cannot see information associated with other
divisions.
A division is a business unit category code (BU CC #1, to be exact), and
therefore is a collection of business units.
We have about 1200 business units, so each individual would have access to
information for about 50 BUs while being excluded from information associated
with the other 1150 BUs.
Here are the ideas we've rejected so far, and the downsides to each:
1) Row security - each division in the company would be setup as a security
group. Each user would belong to one of these groups. That group excludes,
through the use of row security, every business unit not associated with that
division. Essentially, for every security group (division) there would be ~1150
lines of row security. Two problems with this: 1) Performance - it seems like
1150 lines of security for 20 different groups (divisions) would create a
performance hit for the system. Can anyone give a general idea of what this hit
might be like? 2) Maintenance - whenever we have a business unit move from one
division to another we would have to modify every security group, and frequently
we move more than one business unit at a time (10 or more). One potential
solution to the maintenance problem is having a UBE that runs nightly to update
the security records based on any changes in the cost center master (or we could
do it with an RPG program since we're on a 400). Our main concern with this
solution is the performance hit.
2) Security built into individual applications - We could modify applications to
look at the user ID before performing a fetch, locate the user's address book
record, find out which business unit they belong to, determine the division
associated with that BU, and then execute or do not allow the fetch based on
that information. There are a lot of problems with this solution: 1) There are
quite a few inquiries that we would like to give people and this would require
modification of each. 2) There are even more UBEs that people would have
access to, and I guess this would require modifying each of those also. 3)
Every time there is an update/new release for OneWorld our modified applications
and UBEs would get overwritten and would need to be modified again. (Unless we
made copies and kept them in one of the protected systems [55-59], but then
we've still got to create new copies based on the new inquiries if we want to
take advantage of any of the new features in the new release.) 4) Every time
we want the general population to get something new, we've got to modify it to
accommodate security.
3) Adding business unit category code 1 (division) to each business view that
might be fetched against by a user - This is essentially the same as option #2,
except instead of modifying the applications we would be modifying the business
views that those applications use. The general idea is that if we can add BU
cat code 1 (division) to all of those BSVW's then we should be able to secure by
division directly instead of having to secure by business unit to simulate
securing by division. We would still have to add row security for each
division, but it would only exclude 19 or 20 divisions instead of 1100 business
units. The same downsides apply here as apply to #2: 1) There are a lot of
BSVW's that would need to be modified. 2) Those modifications would be
overwritten at each new release.
4) Table Event Rules - At one time we spoke with a JDE representative and they
suggested that we add TER to each table that would perform a security check when
the table is fetched against. Subsequent research has turned up a problem: you
can't stop a fetch through TER even if you find out the user isn't qualified for
the information that they're fetching. The best you can do is clear the fields
on the returning dataset which doesn't seem to be a very desirable solution (and
actually seems potentially dangerous). Does anyone know where to access a fetch
through the C-code to cancel it or whether this might be an option (write a C
business function that's called from TER)?
If anyone has any suggestions about a good approach to securing by a business
unit category code I would greatly appreciate hearing from you. If I have
rejected one of the above ideas out of hand, please let me know if you think
they might be an acceptable solution.
Thanks for your help!
Durbin Black
International SEMATECH
