Re: Application Security Architecture was: Commands for Limited Users

John (and anybody else interested):

Regarding your request for a security scheme, I can offer this to start.
I'm sure there are people out there who will rip it to shreds. The
origins of this go back... a long time. I am trying to reconstruct this
from memory. I lost almost all my information on this in flooding a few
years back. 

It really wasn't object-level security so much as an application
security architecture, of which object-level security was a component. 

Vendor Notice: This scheme depends on programs to work. The origins of
this scheme predate the existence of Penta, PentaSafe and NetIQ and
before I joined them. NetIQ sells applications which can be used as part
of this scheme. However this is not intended to be an endorsement for
them.

The typical profile for this security scheme was a client that used one
or more major vendor application packages plus a large
consulting-house-designed or internally-created application. The
applications plus site-administration tools were typically pushed out to
hosts at other divisions.

This scheme was designed to be 
1) compatible with application packages
2) failure of a security component shouldn't expose data
3) focus on ease of maintenance of the scheme -- minimal places to
update for routine changes; and minimal places to look for problems

This plan involved high-level roles, including application owner,
information creator, information user. There were two application
spaces. Application owner could not sign on. Information creator had
rights to enter the application spaces in which they created
information. Information user usually had a separate spaces outside the
transaction databases in which they worked.

First was the actual transaction database and the programs to work with
it. This was the equivalent of a vendor package. It's libraries were
owned by the application owner, and members of the role of information
creator were allowed to access it. When it didn't go against a vendor's
recommendations, libraries were split apart by general functionality.
For example, general ledger data and customer order data could be split.


Second, a reporting system was built up using the transaction database.
This could be accessed either by tools on the local host or PCs. This
entailed a set of extract files and the programs to extract (and
reformat) the data from the database. This system was typically owned by
the information users. The extracts were segregated by groups of users
and functionality. For example, corporate office users of a local system
had separate libraries from local users of a system. Purchasing had
different libraries than field operations. 

Generally, the only data accessible from the outside the local host were
data in one or more extract libraries.

Libraries and objects were locked down. Permissions were managed by
programs not by the operating system. Programs were used because they
enabled more flexible permission schemes, such as time-based usage,
which was handy in dealing with various cycles. 

The failure of a permissions program usually reverted to object
authority which usually meant the user was not authorized to the data. 

In general, you didn't have access to an object unless a program
determined you should. The exceptions were the data in extract
libraries. It was possible for some data to be accessed without a
program granting approval. In general this was limited to push/pull
interfaces between systems.

When a user was allowed into an application space, the typical scheme
was to use authority adoption. 

The security application was a separate application from the other
applications. Once a user was approved by the security application to
use another application, the security application configured the user's
job as required.

The security application could be checked as often as required. The
security application was generally referenced only when application
domains were crossed. Generally once a user entered an application, that
application's security process was used.

A user could be both an information creator and an information user, but
not usually within an application space. For example, an order entry
clerk was an information creator for customer orders and an information
user for credit information. 

Programs were split from data. In general, we put much tighter controls
on data libraries.

The security application logged all requests to it. The applications
logged most other requests. The in-house and consultant-created
applications adhered to a standardized log format. We had combined log
programs that looked at multiple logs for a user. We didn't present a
command line for most users. We kept joblogs for users who had access to
a command line. 

This was originally designed around closed networks. This scheme
requires some updates for an Internet world. I think the basic
segregation and replication scheme would still be intact. I don't think
I would enable an internet-enabled interface to have direct access to my
transaction databases. I would treat this as another extract-type
library. I'm sure there are other considerations.

Phil Ashe
NetIQ (A division of Attachmate)
1233 West Loop South, Suite 1800 | Houston, TX 77027 USA
713.418.5279 phone
phil.ashe@xxxxxxxxxxxxxx
www.netiq.com  


-----Original Message-----

I've had a standing offer for a couple of years now for someone to

submit a detailed object level security scheme to this list, but I
haven't seen one yet.  Heck, I'd be happy (and amazed) just to see one
from an business application vendor - but haven't seen one of those
either. Maybe I'm just a bit jaded, but I am beginning to suspect that
there isn't a single shop out there that does OLS across their entire
application set the way we all want to believe it could/should be done.

jte