Data security/filtering on field values

My team is developing a new software system that is replacing several
existing applications. The applications being replaced focus on
billing and customer relationship management.

Our company is an international corporation that serves a large number
of customers (hundreds of thousands) spread throughout the US and
Canada. For administrative and accounting reasons, we have divided the
customers into groups based on geographic region (Eastern, Central, and
Western US, Canada). Customers are also grouped within their Region
into Service Areas.

Our new system requires that authorization be performed based on both
the roles of the user (basic RBAC) and on the set of data that the user
is authorized to view and manipulate.

For example, a customer service rep for the West region of the country
should only be able to see and work with customers that are located in
the West region - to this user, the rest of our customers are
irrelevant. The system should behave as though the only customers that
exist are those located in the region with which they work.

In addition, we need to set up non-geographic data filters, such as the
customer classification (similar to SIC code) and value fields such as
Salesperson.

The filtering of data must allow for both unions ("Or") and
intersections ("And") between different security settings; for
instance, we must be able to support the following overlapping sets of
data filters:
1) All customers in the "East" region and all customers with the
classification "Hospital"
2) All "East Hospital" customers (but no Hospitals outside of the
East region or East customers that are not Hospitals)
3) All customers in either the "East" or "West" regions,
regardless of classification

We also need to support the concept of "Data Restrictions", where
the default access to customers with a specific attribute is False
unless a grant is assigned.

We need a solution, whether it is a proven architectural approach or a
third-party technology, which will allow us to apply the defined data
filters at the lowest level of our application as possible with as
little performance impact as possible. We would prefer to implement
something in the database, but if necessary we could implement it in
the data access layer of our software.

The solution should allow flexible definition of 'securable
attributes' of a customer, so that if an additional attributes are
defined in the future we don't need to modify the database structure
or recompile any code.

Questions:
1) Is there a standard or best-practice architectural approach to
applying the sort of security/filtering described above?
2) Are there any third-party tools or technologies that we could
purchase that would provide some or all of this functionality (outside
of hiring consultants to build it for us)?
3) What sorts of approaches have been used before to address this type
of security requirement?

Thanks in advance,

Guy

In article <1116515143.834225.280810@g43g2000cwa.googlegroups.com>,
Guy <gstarbuck@hotmail.com> wrote:
:My team is developing a new software system that is replacing several
:existing applications.

:Our company is an international corporation that serves a large number
f customers (hundreds of thousands) spread throughout the US and
:Canada. For administrative and accounting reasons, we have divided the
:customers into groups based on geographic region (Eastern, Central, and
:Western US, Canada).

Canada covers more time-zones than the USA does, so it might
make sense to make a subdivision within Canada. Manitoba and
westward often resents (to varying degrees) being served out of
Toronto.

:For example, a customer service rep for the West region of the country
:should only be able to see and work with customers that are located in
:the West region - to this user, the rest of our customers are
:irrelevant.

That *sounds* like a reasonable security precaution, but I
would suggest that you review whether it will work in practice.

For example, my [Canadian] bank has an East and a West region,
and there are operations that cannot be done across the boundary
that can be done within the boundary (e.g., re-activating domrant
accounts.) It turns out to be a nuisance. I maintain an
account in the East region at my home town (family plus work travel)
and an account in the West region (where I live), and I don't
want to have to travel a few hundred miles over to the other region
in order to do by business (e.g., transfering money into my East
account in preparation for travel there.)

The customer perspective is that your business is all one company. If
a business whose main office is in Chicago whose CEO is on a business
trip cannot call up one of your people in San Francisco for a deal (a
financial transaction, place an order, whatever) because the
region boundaries, then that CEO isn't going to be very pleased.

In the bank I mentioned, there is -some- provision for cross-region
transactions. Some of them require extra levels of authentication
(e.g., the regular teller plus an override from a supervisor).
That's often a reasonable compromise: not that the data just can't
be seen from the other locations, but rather that doing so
requires multi-factor authentication, making it less like that
(for example) a movie star's data would be visible to a low-level
rep in an obscure branch office.


:We need a solution, whether it is a proven architectural approach or a
:third-party technology, which will allow us to apply the defined data
:filters at the lowest level of our application as possible with as
:little performance impact as possible.

DCE possibly -- it's built to be able to handle complex
security relationships with hooks right in the application.

DCE is definitely not trivial to set up: back when I was looking
at it, I was seeing figures such as "Expect to invest at least
$100,000 and 2 years in order to implement it and put all
the hooks in." But yes, with proper DCE security roles set up
and proper code hooks, unauthorized data just isn't -there-:
no reliance on fail-prone techniques such as sending all the
data and counting on the client side to only print the
ones it thinks the user is authorized to see.
--
Entropy is the logarithm of probability -- Boltzmann