[ Pobierz całość w formacie PDF ]
.Moreover,we can generalize this beyond users to other types of accessor as the need arises.Themodel built so far is known in the academic literature as RBAC0.Adding HierarchyAs RBAC can operate at a much more general level than ACL, it will often happenthat one role embraces another.Suppose we think of the example of a hospital, therole of consultant might include the role of doctor.Not everyone who has the role ofdoctor would have the role of consultant.But all consultants are doctors.At present, Aliro implements hierarchy purely for backwards compatibility withthe Mambo, and Joomla! schemes, where there is a strict hierarchy of roles forACL.The ability to extend hierarchy more generally is feasible, given the Aliroimplementation, and may be added at some point.The model with the addition of role hierarchies is known as RBAC1.Adding ConstraintsIn general data processing, situations arise where RBAC is expected to implementconstraints on the allocation of roles.A typical example would be that the sameperson is not permitted to have both purchasing and account manager roles.Restrictions of this kind derive from fairly obvious principles to limit scope for fraud.While constraints can be powerful additions to RBAC, they do not often arise in webapplications, so Aliro does not presently provide any capability for constraints.Theoption is not precluded, since constraints are typically grafted on top of an RBACsystem that does not have them.Adding constraints to the basic RBAC0 model creates an RBAC2 model, and if bothhierarchy and constraints are provided, the model is called RBAC3.Avoiding Unnecessary RestrictionsWhen it comes to design an implementation, it would be a pity to create obstaclesthat will be troublesome later.To achieve maximum flexibility, few restrictions areplaced on the information that is stored by the RBAC system.[ 121 ] Access ControlSubjects and accessors have both types, and identifiers.The types can be strings, andthere is no need for the RBAC system to limit what can be used in this respect.Amoderate limitation on length is not unduly restrictive.It is up to the wider CMS todecide, for example, what kinds of subjects are needed.Our example for this chapteris the file repository, and the subjects it needs are known to the designer of therepository.All requests to the RBAC system from the file repository will take accountof this knowledge.Identifiers will often be simple numbers, probably derived from an auto-incrementprimary key in the database.But it would be unduly restrictive to insist thatidentifiers must be numbers.It may be that control is needed over subjects thatcannot be identified by a number.Maybe the subject can only be identified by a non-numeric key such as a URI, or maybe it needs more than one field to pick it out.For these reasons, it is better to implement the RBAC system with the identifiers asstrings, possibly with quite generous length constraints.That way, the designersof software that makes use of the RBAC system have the maximum opportunity toconstruct identifiers that work in a particular context.Any number of schemes canbe imagined that will combine multiple fields into a string; after all, the only thingwe will do with the identifier in the RBAC system is to test for equality.Providedidentifiers are unique, their precise structure does not matter.The only point towatch is making sure that whatever the original identifier may be, it is consistentlyconverted into a string.Actions can be simple strings, since they are merely arbitrary labels.Again, theirmeaning is important only within the area that is applying RBAC, so the actualRBAC system does not need to impose any restrictions.Length need not beespecially large.Roles are similar, although systems sometimes include a table of roles because extrainformation is held, such as a description of the role.But since this is not really arequirement of RBAC, the system built here will not demand descriptions for roles,and will permit a role to be any arbitrary string.While descriptions can be useful, itis easy to provide them as an optional extra.Avoiding making them a requirementkeeps the system as flexible as possible, and makes it much easier to create roles onthe fly, something that will often be needed.Some Special RolesHandling access controls can be made easier and more efficient by inventing someroles that have their own special properties.Aliro uses three of these: visitor,registered, and nobody.[ 122 ] Chapter 6Everyone who comes to the site is counted as a visitor, and is therefore implicitlygiven the role visitor.If a right is granted to this role, it is assumed that it is grantedto everybody.After all, it is illogical to give a right to a visitor, and deny it to a userwho has logged in, since the user could gain the access right just by logging out.For the sake of efficient implementation of the visitor role, two things are done [ Pobierz całość w formacie PDF ]