11.07.2015 Views

Borland VisiBroker® 7.0 - Borland Technical Publications

Borland VisiBroker® 7.0 - Borland Technical Publications

Borland VisiBroker® 7.0 - Borland Technical Publications

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Defining access control with Role DBUsing logical operators with assertionsTwo logical operators are available in specifying attribute/value pairs.Table 4.1Logical Operators for Authorization AssertionsOperator Description Exampleattribute = value equals: attribute must equal value for authorization rule to CN=Russ Simmonssucceed.attribute != value not equal: attribute must not equal value for authorizationrule to succeed.CN!=Rick FarberA value can be any string, but the wildcard character, “*” has special uses. Forexample, the attribute/value pair GROUP=* matches for all GROUPs. The following rolehas two associated rules:manager {CN=Kitty, GROUP=*GROUP=SalesForce1, CN=*}The role manager has two rules associated with it. In the first rule, anyone named Kittyis authorized for manager, regardless of Kitty's associated group at the time. The secondrule authorizes anyone in the group SalesForce1, regardless of their common-name(CN).Wildcard assertionsFor complicated security hierarchies, it may be prudent to only look for only one or twoattributes from the hierarchy in order to authorize a principal. <strong>Borland</strong>'s securityhierarchy starts with GROUPs at the top, then branching out into ORGANIZATIONs(O) and ORGANIZATIONAL UNITS (OU), and finally settling on COMMON NAMEs(CN).For example, you may want to define a security role called SalesSupervisor that allowsmethod permissions for managers of the sales force. (For this example, “sales” is theORGANIZATION and “managers” is the ORGANIZATIONAL UNIT. You could do sowith the following rule:SalesSupervisor {GROUP=*, O=sales, OU=managers, CN=*}This rule does not specify values for GROUP or for COMMON NAME (presumablybecause they are not necessary). But remember, each rule must represent all possiblevalues for a Principal's credentials. There are other means of representing this sameinformation in a smaller space using wildcard assertions.You make a wildcard assertion by placing the wildcard character (“*”) in front of theassertion(s) in one of two ways. You may place the wildcard character in front of asingle assertion, meaning that all possible security attributes are accepted but theymust contain the single assertion. Or, you may place the wildcard character in front of alist of assertions separated by commas within parentheses. This means all possiblesecurity attributes are accepted but they must contain the assertions listed in theparentheses.Chapter 4: Authorization 45

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!