Patterns affecting ABL permissions

Table 5. Granting or denying ABL permissions
If the user ID matches...	This pattern...	Grant/Deny permission...
No	!pattern-entry1,pattern-entry2	Deny
Yes	pattern-entry	Grant
Yes	!pattern-entry	Deny

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.

Table 6. Wild cards in user ID patterns
This pattern...	Matches...
	The blank user ID
*	All user ID's
mark	The user ID, "mark"
mark*	All user ID's that begin with "mark"
*jones	All user ID's that end with "jones"
db*user	All user ID's that begin with "db" and end with "user"

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.

!user-id-pattern[,!user-id-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 11.0 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 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 7. 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 8. 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"
"*"	"*"	"*"

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.

Caution: The CAN-DO function treats '@' as a domain delimiter by default, but this behavior can be changed by setting the CAN-DO-DOMAIN-SUPPORT attribute on the SECURITY-POLICY handle to FALSE or by using the -nocandodomain startup parameter. For more information, see OpenEdge Development: ABL Reference and OpenEdge Deployment: Startup Command and Parameter Reference.

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@"

Table 9. Fully qualified user ID matches
This pattern...	Matches...
	The blank user name in the blank domain
*	All user ID's
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"