Browse Prior Art Database

Registration-Based Software Security

IP.com Disclosure Number: IPCOM000113519D
Original Publication Date: 1994-Sep-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 111K

Publishing Venue

IBM

Related People

Davis, RA: AUTHOR [+2]

Abstract

Computer systems typically provide security by requiring a user logon sequence to gain access to the system; the logon sequence is often combined with the definition of groups of resources, providing a means by which specific classes of users are granted access to specific system resources. For example, with IBM's mainframe-based VM, a user is given access to various disk or file resources; with PC-based local area networks (LANs), users are given access to various disk, device, or even application resources (the entire application being considered as a resource).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

Registration-Based Software Security

      Computer systems typically provide security by requiring a user
logon sequence to gain access to the system; the logon sequence is
often combined with the definition of groups of resources, providing
a means by which specific classes of users are granted access to
specific system resources.  For example, with IBM's mainframe-based
VM, a user is given access to various disk or file resources; with
PC-based local area networks (LANs), users are given access to
various disk, device, or even application resources (the entire
application being considered as a resource).

      The model described herein for registration-based software
security (RBSS) improves on conventional security strategies by
permitting registration of specific sections of an application to be
secured, so that the application can define the degree of granularity
with which security is applied to its function set.

      Description - RBSS accommodates all methods currently used to
implement security, including user logons and the defining of groups;
in addition, BRSS permits the application programmer to define
security points within an application, then to assign the appropriate
security level to each point.

      To implement security points, the system security component
must expose two application programming interface (API) functions
used by the application programmer--one API to define a security
point and another to validate a previously defined security point.

      For performance considerations, it is recommended that security
point definition be implemented only when the application is
initially installed and that the security points be removed from the
system whenever an application is removed.

      OPERATION - When defining the security point, the application
provides a text string that describes the section of the application
being secured, a number uniquely identifying the point to the
application, and an identifier (defined by the operating system or
security system) that uniquely identifies the application.

      As an example, consider an application that performs file
create, file delete, and file edit functions, where it is desirable
to associate different security levels with each function.  Such an
application, might include the following code:
  DefineSecurityPoint("File Add", 1, iden)
  DefineSecurityPoint("File Delete", 2, iden)
  DefineSecurityPoint("File Edit", 3, iden)

      Here the application has defined three security points--file
add, file delete, and file edit, identified as 1, 2, and 3
respectively.  When validating the security point, the application
provides its unique identifier ("iden")  and the identifier it uses
to refer to the security point being validated.  Before entering the
code segment for the action that is secured, the application
programmer would issue the validate function.

Using the example given, that validation sequence might look li...