Authorizing users from within a given procedure

DEFINE VARIABLE selection AS INTEGER NO-UNDO FORMAT "9".
RUN _prostar.p.

REPEAT:
  FORM  SKIP(2)    "    M A I N M E N U"
      SKIP(1)    "  1)  Add a new customer"
      SKIP(1)    "  2)  Change customer Information"
      SKIP(1)    "  3)  Display orders"
      SKIP(1)    "  4)  Create mailing labels"
      SKIP(1)    "  5)  Delete a customer"
      SKIP(1)    "  6)  EXIT"
  WITH CENTERED TITLE "Maintenance and Reporting".
  UPDATE SKIP(2) SPACE(1) selection AUTO-RETURN
    WITH SIDE LABELS.
  HIDE.
       IF selection EQ 1 THEN RUN i-adcust.p.
  ELSE IF selection EQ 2 THEN RUN i-chcust.p.
  ELSE IF selection EQ 3 THEN RUN i-itlist.p.
  ELSE IF selection EQ 4 THEN RUN i-rept6.p.
  ELSE IF selection EQ 5 THEN RUN i-delcus.p.
  ELSE IF selection EQ 6 THEN QUIT.
  ELSE MESSAGE "Incorrect selection - please try again".
END.

You can define, on a per procedure basis, the individuals who can run each of the Maintenance and Reporting menu procedures. Use the CAN–DO function to check the user ID(s) established by _prostar.p. The i-adcust.p procedure allows you to enter Customer information.

REPEAT:
INSERT Customer WITH 2 COLUMNS.
END.

If you want to limit the use of this procedure to database connections that have a database connection ID of manager or salesrep, you can modify the procedure shown in i-adcus2.p to authorize access based on the database connection ID for single connected database:

The first part of i-adcus2.p authorizes the user to run the procedure. The CAN–DO function compares the values listed in the parentheses against the database connection ID for a single connected database. If the database connection ID does not match any of the values listed, the procedure displays a message and exits. If the database connection ID does match one of the values (listed user IDs), the procedure continues executing.

The user ID pattern list you provide in the CAN–DO function is a comma-separated list of user ID tokens. You can use tokens to indicate specific users who have or do not have access. The following table lists the types of tokens you can specify.

Table 18. Values to use for user ID pattern lists
Value	Meaning
*	All users are allowed access
user	This user has access
!user	This user does not have access
string*	Users whose IDs begin with string have access
!string*	Users whose IDs begin with string do not have access

You can use any combination of patterns to define user ID pattern lists. These patterns are fully consistent with the permissions that you can define for OpenEdge database tables and fields using database administration tools.

Table 19. Fully-qualified user ID matches
This pattern...	Matches...
	The blank user name in the blank domain
*	All user IDs
mark@acme.com	The "mark" user name in the "acme.com" domain
mark	The "mark" user name in the blank domain
mark*	All user names that begin with "mark" in the blank domain
*jones	All user names that end with "jones" in the blank domain
db*user	All user names that begin with "db" and end with "user" in the blank domain
@acme	The blank user name in the "acme" domain
*@acme	All user names in the "acme" domain
@	The blank user name in the blank domain
mark@*	The "mark" user name in any domain
@	Any user name in any domain
mark@acme.	Any user name that begins with "mark" in any domain that begins with "acme."
@.admins	Any user name in any domain that ends with ".admins"

For a more complete description of the possible patterns and their meanings, see OpenEdge Getting Started: Identity Management and the Database Administration online help. For more information on the CAN–DO function, see OpenEdge Development: ABL Reference.

The USERID function (with a specified or single database connection) allows you to check user IDs in a procedure. Use the function in i-adcus3.p when you want to allow only one user ID access to a procedure.

If you use either the CAN–DO function or the USERID function to compare the specified database connection ID with one or more user IDs you hard-code in a procedure, you must modify and recompile that procedure whenever you change the user IDs allowed access to it. You can avoid having to make these changes by building a permissions table for activities in your application. For more information, see Defining activities-based user authorization.

Also, given a single string of user IDs, the CAN-DO function, by default, validates the single USERID (database connection ID) value for a single database connection. If you connect to more than one database, a USERID function requires a specified logical database name and a CAN–DO function requires a second argument consisting of an explicit USERID function with a specified logical database name.

The second argument of the CAN-DO function can also consist of a string expression that specifies an authenticated user ID other than the database connection ID. For example, you can specify the USER-ID attribute of a client-principal object validated against the application trusted domain registry to specify the OpenEdge session ID. In this way, you can use the CAN-DO function to authorize procedure access independent of any database connection. For more information, see Elements for authenticating ABL user identity. You can also use the list of user roles set for the ROLES attribute on the client-principal object to identify user permissions for the CAN-DO function, for example: