Patterns affecting ABL permissions

The following table shows how a user ID match to denying or granting patterns affects ABL permissions.

The patterns contained in tables and field permission entries support wildcard characters '*' and '.', for multi-character matches and single character matches respectively. The following table lists examples of supported wildcard patterns.

The ABL permissions can be configured either in a deny authorization model or in an industry standard grant authorization model. A deny model is when all users are granted permission and specific users are denied permission. This deny authorization model is no longer recommended best practice as its default is to grant a new user account access unless otherwise denied. The grant authorization model is the industry recommended type, and in this model a user account is denied access until explicitly granted. The grant model is stronger as it denies new user accounts access until the DBA explicitly grants them access. The basic forms of ABL permission lists for the two authorization models are as follows.

To deny permissions, use this pattern:

!user-id-pattern[,!user-id-pattern]...,*

To grant permissions, use this pattern:

user-id-pattern[,user-id-pattern]...

As illustrated above, non-multi-tenant databases use non-qualified user ID's for permission checking, while multi-tenant databases use fully qualified user ID's. OpenEdge extends its ABL permission checking to use either non-qualified or fully qualified user ID's at all times. In this way, databases with existing user ID patterns continue to work while a database is being converted to multi-tenancy and back. During conversion, all data is moved to the default tenant, so existing non-qualified user IDs continue to work.

The user ID's and ID patterns used for permission checking change as follows:

• The user ID is split into two fields: the user name and the domain name (minus the '@' domain delimiter). If the user ID does not contain a domain name delimiter, the blank domain name is assumed. The following table shows some examples.

  Table 3. User ID changes for DB multi-tenancy conversion

  Source user ID	User name used for pattern matching	Domain name used for pattern matching
  "rjones"	"rjones"	"" (blank domain name)
  "rjones@acme.com"	"rjones"	"acme.com"

• The ID pattern entry is split into two patterns: the user name pattern and the domain name pattern (minus the '@' domain delimiter). If the pattern does not contain a domain name delimiter, the blank domain name is assumed. The following table shows some examples.

  Table 4. ID pattern changes for DB multi-tenancy conversion

  Source pattern entry	User name used for pattern matching	Domain name used for pattern matching
  "rjones"	"rjones"	"" (blank domain name)
  "rjones@acme.com"	"rjones"	"acme.com"
  "*"	"*"	"*"

• For a pattern match to occur between a user ID and a pattern entry:
  • The pattern entry contains the single wildcard pattern '*', which always matches both the user name and the domain name.
  • A match must exist between the user ID's user name and the pattern entry's user-name pattern and between the user ID's domain name and the pattern entry's domain-name pattern.

The use of wildcards in patterns produces some equivalencies between non-qualified and fully qualified user IDs and ID patterns. For non-qualified user ID patterns, full qualification is implied:

"*" == "*@*"
""  == "@"
"mark" == "mark@"

The following table shows some examples of fully qualified user ID matches.