Borland VisiBroker® 7.0 - Borland Technical Publications

Authorization domainsMaking use of wildcard assertions, the role could also look like this:SalesSupervisor {*O=sales, *OU=managers}Or, even more simply:SalesSupervisor {*(O=sales, OU=managers)}All three code samples are different versions of the same rule.Other assertionsAuthorization domainsEach role provides limited extensibility to others. You may, as a part of a role entry,specify a role=existing-role-name assertion that can extend an earlier role. You canalso use customized code as your authorization mechanism rather than Role DBsyntax by using the Authorization Provider Interface.Recycling an existing roleYou can refer to the rules from an existing role by using the rule-reference assertion—role=role-name. For example, let's say we have a group of marketers who are alsosales supervisors that need to be authorized to the same code as Sales Supervisors.Building upon the SalesSupervisor code sample, we can create a new role entry asfollows:MarketSales {role=SalesSupervisor*(OU=marketing)}Now, everyone in role SalesSupervisor has access to the MarketSales role, as doesanyone in the “marketing” OU.NoteEach Role DB file is associated with an authorization domain. An authorization domainis a security context that is used to separate role DBs and hence their authorizationpermissions. For more information on the authorization domain in the context of thebasic security model, see “Basic security model” on page 9.EJBs can be deployed to multiple security contexts with different permissions androles.An authorization domain is associated with an EJB in its deployment descriptor.You may use as many authorization domains as you wish, provided they are allregistered with the VisiBroker ORB. You must do the following for each of yourauthorization domains:■■■■give it a name,set up default access,set up the Role DB,and set up alias(es).46 VisiBroker Security Guide