The Common Models

The CIM common models are listed in Table 3.1 on page 20. I describe the system, network, user , and policy models later because these are of particular importance to the telecommunications industry. Additionally, the Interop and Event models are described elsewhere in this book as indicated in the table.

The System Model

A System is a collection of elements which work together to provide a particular functionality. To some extent a system is therefore just a collection but, to be a system, the collected items must be synergistic ” the collection must offer more than the sum of its components .

Typically a system will have a name and this is another way of recognising a system. Except, for example, in very specialised applications, a computer would have a name (e.g., saturn@hobbs) whereas its keyboard would not. The computer might therefore be a System, but the keyboard would not. Within the System Common Model, CIM_ComputerSystem is a CIM_System and its presence this high in the class hierarchy may depend more on the history of the CIM models (arising from the desktop computing environment) rather than its actual importance. Having said that, computing devices do appear in many devices being managed. Remember, however, that CIM_System is a CIM_LogicalElement, not a CIM_PhysicalElement ”we are talking here of the logical function of computing, not the physical computer.

Not all Systems are as obviously Systems as is CIM_Computer-System. An OSPF Area (if necessary, see the glossary entry for OSPF), represented by CIM_OSPFArea in the Network Common Model, is also, ultimately, a CIM_System through being a CIM_RoutingProtocolDomain which is, in turn , a CIM_AdminDomain.

So, does an OSPF Area comply with the guidelines for being a System? Of what is it a collection? Does it add any synergy not provided by the individual elements? Could you name it?

OSPF is defined in the IETF specification RFC2328, which contains the statement:

OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group , together with the routers having interfaces to any one of the included networks, is called an area.

Given this description, an OSPF Area is certainly a collection ”the RFC even uses the word "collection" directly. RFC2328 goes on to say:

Each area runs a separate copy of the basic link-state routing algorithm. This means that each area has its own link-state database and corresponding graph.

which implies that an OSPF Area is not just a random collection of unrelated entities ”by grouping them into a collection like this extra functionality emerges: routing tables based on common link-state databases can be calculated and IP packets can be efficiently routed.

Of course, an OSPF Area can also be named: it has an Area Identity defined in the mof file as follows :

 [Description  (       "The area ID of this OSPF area, see C.2 "             "in RFC 2328."),        MappingStrings             {"MIB.IETFOSPF-MIB.ospfAreaId"} ]     uint32 AreaID; 

These are the characteristics of a CIM_System and it is therefore right that a CIM_OSPF Area should be a CIM_System.

Summary of the System Model

A system is a collection which is more than the sum of its parts .

 

The Network Model

In other parts of this book I have given brief explanations of network terms (OSPF, BGP, etc.) as they have arisen. I assume that, if you're reading this chapter, then you're probably interested in, and knowledgeable about, telecommunications networks and so I will drop the explanations .

The Network Common Model is enormous , is incomplete and has undergone radical change as the DMTF's Networks Working Group has partially unwound and rebuilt the original models ”work which is still in progress. In version 2.7 of the core and common files, the Network Model accounts for 11,422 of the 52,218 total lines of mof ”i.e., 22 percent of the core and common mof is Network Model. Given this size it is difficult to find a way into the model and understand its basic structure. To help with this, the DMTF has issued a white paper, DSP0152, dedicated solely to the Network Model (also one dedicated to the OSPF submodel : DSP0160).

The best way into the Network Model is through its services, but before diving into the details, it is perhaps useful to discuss the use of the term "Service" in the Network Model: the internal protocols used by the IP Network being managed are modelled as services (for example, CIM_OSPFService is a CIM_RouteCalculationService which is a CIM_NetworkService which is a CIM_Service). Generally , OSPF would not be seen by users of a network but, as I have said previously, services can exist at different levels and this is one example of that flexibility.

As illustrated in Figure 6.4, the fundamental services which it is assumed that the network offers are:

• Virtual Local Area Network (VLAN) Service

• So-called Network Services; the forwarding of packets at layer-2 or layer-3 and calculation of routing tables

• SNMP (yes, one management system managing the service offered by another!)

• Quality of Service (yes, Quality of Service (QoS) is a service ”if you find this difficult to understand, then wait a page or so for the explanation.)

Figure 6.4: Part of the Network Model

These services clearly illustrate the current orientation of the Network Model ”towards enterprise IP networks running on Local Area Networks. Within the full Network Model, concession is made to the Wide-Area Network; Local Area Networks may be modelled as being connected by CIM_NetworkPipes: very simple representations of the underlying Wide Area Network connections. The details of Wide Area Networks (SDH, SONET, Wavelength Division Multiplexing, fibre management, etc.) and layer 2 networks (MPLS, ^[3] ATM, Frame Relay) are currently missing from the models. The omission of the WAN and layer 2 networks is likely to be remedied soon.

The Network, SNMP and QoS Services are sufficiently important to be considered in detail; see the following subsections.

Network Service

As I described on page 92, services are always associated with CIM_ServiceAccessPoints. So, if routing and forwarding are to be services, we expect to see their Service Access Points: the places at which these services "appear" and can be accessed. To this end, CIM_ServiceAccessPoint is subclassed to CIM_ProtocolEndpoint as illustrated in Figure 6.5. The endpoints of different protocols (IP, BGP, OSPF, TCP, UDP) are all represented as CIM_ProtocolEndpoints.

Figure 6.5: Part of the Protocol Endpoint Model

We may want to associate protocol endpoints in one of two ways:

1. By saying that endpoint A is (or may be) connected to endpoint B. Clearly, for this to occur the two endpoints must be of the same type: connecting a LAN Endpoint to a TCP Endpoint is meaningless. The association CIM_ActiveConnection which is defined between two endpoints (actually between two CIM_ServiceAccessPoints and inherited by the endpoints) is used to indicate this type of connection.

2. By saying that endpoint A "rests on" endpoint B. This occurs in multilayer networks: BGP endpoint A runs on TCP endpoint B, which runs on IP endpoint C, which runs on Frame Relay endpoint D, which runs on ATM endpoint E, which runs on DWDM endpoint F, which runs on fibre endpoint G. Endpoints A to G are all in the same place, but are at different protocol levels. This type of relationship between endpoints is indicated by the CIM_BindsTo association.

The only concessions made in the Network Model at present to the underlying Wide Area Network are the classes describing a so-called "Network Pipe." Reasonably enough, the concept of a Pipe is taken from an ITU-T specification: M.3100 "Generic Network Information Model." To bind these two specifications together, the mof definition of the CIM_NetworkPipe model contains the mappings:

 MappingStrings {"Recommendation.ITUM3100.Pipe",     "Recommendation.ITUM3100.TrailR1",     "Recommendation.ITUM3100.ConnectionR1",     "Recommendation.ITUM3100.SubNetworkConnection"} 

This is an example of the mapping string used to map a CIM class to an ITU rather than SNMP definition: for a more complete description of the MappingStrings qualifier, see Appendix E.

The CIM_NetworkPipe class contains a number of properties including whether the pipe is bidirectional, whether it comprises a number of lower-speed pipes and its required and actual states.

SNMP Service

One area of the Network Model of particular interest for interoperability is the SNMP sub-tree. Given the ubiquity of SNMP management systems, it is likely that WBEM will often have to co-exist on the same device as an SNMP agent. In this case it could be useful for the WBEM operator to be able to manage the local SNMP agent.

I have illustrated some of the relevant classes in Figure 6.6. Note that, in order to show clearly how classes are associated with CIM_SNMPService, I have used a nonstandard manner of drawing the association: as a dotted line to indicate inheritance from the solid lines.

Figure 6.6: The SNMP Sub-Tree

The heart of the SNMP interworking is the CIM_SNMPService class. Even though this class has neither properties nor members , it ties together the other classes associated with a particular SNMP implementation.

In order to access an SNMP agent you need to know a password, known in SNMP-speak as a Community String. This is held, together with details of the authority that an operator using the Community String has (i.e., read-only access, read-and-write access), in one or more instances of the CIM_SNMPCommunityString class. Instances of this class are tied to the CIM_SNMPService through the CIM_ServiceAccessBySAP association.

An alarm or indication is known, by SNMP experts, as a Trap. Instances of the CIM_SNMPTrapTarget class allow you to specify remote addresses to which SNMP traps should be sent. Again, this class is associated with an CIM_SNMPService instance, this time through the CIM_ServiceSAPDependency association. The CIM_SNMPTrapTarget class has a number of properties, including another Community String, mainly concerned with locating the remote server: a host address and the UDP port to which the traps are to be delivered (defaulting to port 162).

These classes tie the destination for the SNMP traps to the SNMP service. It is also necessary to define the origin of the traps: what is generating them? The originator is modelled as a CIM_ProtocolEndpoint, thus providing its IP address.

I give more information about possible SNMP to WBEM/CIM migration routes in Chapter 14.

QoS Service

There is one further significant CIM_Service defined in the Network Model: Quality of Service (QoS). This naming again reflects the origin of the Network Model in the packet- rather than circuit-switching area. In the packet world, Quality of Service is not a characteristic of any and all services, it is a shorthand for a particular service: the service that allows different customers to have their packets treated in different ways as they pass through IP routers. If we were both customers of a particular network operator, by paying more, you could ensure that your packets took precedence over mine in various queues in the routers and you would then have bought a "Quality of Service" Service.

In preparing the QoS submodel, the DMTF has worked closely with the IETF and at the time of writing, an IETF standard is due to emerge containing details of a model common to the DMTF and the IETF. This is currently in draft form as "Information Model for Describing Network Device QoS Datapath Mechanisms."

The Quality of Service submodel divides the components of QoS into two: the basic mechanisms for marking, dropping and metering IP packets which are collectively known as Conditioning Services and the aggregation of these into a service sold to a particular customer, for example, through Differentiated Services (RFC2474).

The two classes CIM_DiffServService and CIM_ConditioningService are shown in Figure 6.7 with a few of their subclasses. CIM_DiffServService, in particular, is subclassed into CIM_AFService and CIM_EFService to describe Assured Forwarding (AF) and Expedited Forwarding (EF) respectively. Because Expedited Forwarding does not actually require any more modelling than can be supplied by the CIM_ClassifierService and CIM_DiffServService classes, its use has now been deprecated; I have included it here because anyone knowledgeable in this area hearing of a class for the AF service would be waiting for the other shoe to fall, "What about EF service?"

Figure 6.7: Part of the QoS Service Hierarchy

We would expect that a service such as DiffServ would make use of the component services (packet metering, classifying, and dropping) and, as expected, such an aggregation does exist, CIM_QoSConditioningSubService, which aggregates the lower-level components into the higher-level service.

Equally, different DiffServ components might be combined to form a composite service for a particular customer. Thus the service "Customer X gets bronze service" would map through the CIM_QoSSubService aggregation to lower-level services which could be based on the various conditioning services reached through CIM_QosConditioningSubService.

Apart from considering the services, there is one other useful classification within the Network Model: by administrative domain. The term "administrative domain" is used as a general term to mean some collection of network elements which together form a coherent whole and which can be combined with other administrative domains to create a higher-level domain. In the simplest case an administrative domain may be geographical: the Ontario domain and the Qubec domain combining to form the East Central domain. The term is, however, more abstract than this and could refer to any hierarchical grouping.

Summary of the Network Model

The Network Model provides the infrastructure for managing network services: primarily routing, forwarding, SNMP, and QoS.

 

The Policy Model

The most important question here, of course, is, "What is meant by the term 'policy' ?" A political party may have a policy of fiscal conservatism. I may have a policy of never going near small children, particularly grubby ones. Are these policies which can be modelled using the Policy Common Model? The answer is, only if they can be expressed in the form

 IF (cond1 AND cond2) OR (cond1 and cond3) THEN action 

It might be hard to express fiscal conservatism in this manner, but in principle, my aversion to children could be expressed as:

 IF ((age lessThan 10) AND (person is grubby)) THEN avoid 

Of course, I may wish to make exceptions to a rule: perhaps I want to avoid all grubby children except my own, George. I could then add a rule which says that:

 IF (child is George) THEN provide bath 

If George is under 10 years old and grubby, then both rules would be true and some mechanism must be defined to choose between them: do I avoid him or provide a bath? The answer, of course, is that I must be able to prioritise the rules and this is something that CIM provides.

More usefully in a telecommunications network one can imagine policies of the type

 IF (customerClass is 1) AND              (currentTrafficLevel lessThan 45 percent)              THEN accept connection 

Rules such as these would typically define the Service-Level Agreement (SLA) between a supplier (carrier) and a customer: "I will carry your traffic under these conditions."

The DMTF is working with the IETF to produce a formal description of a policy. This collaboration has produced RFC3460, which is entitled "Policy Core Information Model (PCIM) Extensions," and this, read in conjunction with the mof code, probably provides the best description of policies. RFC3460 itself is an update of RFC3060, entitled "Policy Core Information Model," and, as an introduction, RFC3060 is probably the better specification to read: it contains more description of policies without details of their application to particular IP routing elements.

Another useful document to help you wade through the policy swamp is RFC3198 entitled "Terminology for Policy-Based Management."

Figure 6.8 shows a small part of the Policy Common Model. Remember that the open diamonds represent aggregation (refer back to section 5 if necessary): a CIM_PolicyRule aggregates CIM_PolicyConditions ( IF X IS Y ...) and CIM_PolicyActions (... THEN Z ).

Figure 6.8: Part of the Policy Hierarchy

Although CIM_PolicyRule has many properties, I have chosen to include only two in Figure 6.8: ConditionListType and Enabled. ConditionListType is an enumerated variable which can take two values: disjunctive normal form (DNF) or conjunctive normal form (CNF). These are impressive terms to describe how the conditions are to be combined: in either case the conditions are grouped (by using the GroupNumber property on the CIM_PolicyConditionInPolicyRule association ”see Figure 6.8). Assume that a rule has 6 conditions with the Group-Number and ConditionNegated properties as shown in Table 6.1.

Table 6.1: Conditions

Condition	GroupNumber	ConditionNegated	Example
C1	45	False	Tuesday is the day before Wednesday
C2	43	False	2 + 5 = 6
C3	76	True	3 5 = 16
C4	45	False	Canada lies to the north of the USA
C5	45	True	The capital of Canada is Toronto
C6	43	False	France is a monarchy

If the rule had the property of being expressed in Disjunctive Normal Form (DNF), then the conditions would be interpreted as

whereas if the rule were in Conjunctive Normal Form (CNF) then the conditions would be interpreted as

In each case, the NOT term arises from the ConditionNegated values. Given the example statements in the right-hand column of Table 6.1, ^[4] the Disjunctive Normal Form version would evaluate to

 (T and T and (not F)) or (F and F) or (not F) i.e. (T and T and T)       or (F and F) or (T) i.e. (T)                   or (F)       or (T) 

which evaluates to TRUE (because both the first and third terms are TRUE). The Conjunctive Normal Form version, on the other hand, would evaluate to

 (T or T or (not F)) and (F or F) and (not F) i.e. (T or T or T)       and (F or F) and (T) i.e. (T)                 and (F)      and (T) 

which evaluates to FALSE (because the second term is False).

This example illustrates the flexibility you have when combining conditions in a CIM_PolicyRule: you can negate any particular condition and then combine the resulting conditions in a flurry of ORs and ANDs.

The remaining question is how to express the conditions and actions. What language is used? We will start with conditions. As you can see in Figure 6.8, the common model defines three subclasses of CIM_PolicyCondition:

• CIM_PolicyTimePeriodCondition which allows you to specify time periods. For example, you could specify a condition that is true from 1st January 2005 to 17th June 2006, but only between 08:00 and 23:00 and only on Thursdays. Like any other condition, this can be combined (after being negated if necessary) with other conditions using OR and AND .

• CIM_AuthenticationCondition is designed to hold a condition defining how an operator is to be authenticated. You can consider it as a condition of the type "If the operator has been validated in accordance with X ..." To this end it has properties defining the type of validation (Shared Secret, Biometric {using mark, finger, voice, retina , DNA, EEG}, Public/Private Key Pair, Kerberos Ticket, Physical Credential, etc.) and the parameters and addresses required to complete the authentication. I discuss the use of this type of condition when considering the User Model below.

• CIM_VendorPolicyCondition which allows you to specify any condition, in a language of your choice. The class contains two fields which you can use to define the condition: Constraint and ConstraintEncoding. The DMTF has not specified a particular language and so any standard constraint language could be used. This is kept general by putting the OID of the language (e.g., 1.2.100.200) into the ConstraintEncoding field. Of course, your management software will have to include an interpreter to evaluate the condition in whatever language you have chosen and determine whether it is true or false.

  If you are using models from another source, your software could query the ConstraintEncoding property to decide whether it can handle the language or not. There may even be a policy to be followed if the software cannot handle the condition language (although encoding that policy might be hard!).

Because most conditions are likely to be simple ("property X has a value of Y"), RFC3460 subclasses CIM_PolicyCondition with an additional class, SimplePolicyCondition, which is designed to express precisely this type of condition:

 DestinationPort MATCH {'80', '8080'} DestinationPort MATCH {'1 to 255'} DestinationPort MATCH '80' 

Having grasped the encoding of conditions, you now implicitly understand the encoding of actions ”it uses the same technique in that you get to choose the language and then specify an action and language in the ActionData and ActionEncoding properties of CIM_Vendor-PolicyAction. Because most actions are also likely to be simple ("set property X to the value Y"), RFC3460 subclasses CIM_PolicyAction with a new class, SimplePolicyAction, which is designed to express precisely this type of action (does this sound familiar?):

 Set Status to 'ON' 

As I have described them so far, there are two fundamental problems associated with policies:

• There could be an enormous number of them in a system. Maintaining these would be tedious and so the DMTF and IETF have introduced the concept of a role which I discuss below.

• There could be inconsistencies between the conditions or the conditions, when combined, could be inconsistent with the actual system resources ("Joe can have 50 percent of the bandwidth and Bill can have 70 percent"). Detecting such inconsistencies is a research problem and Cisco Systems is sponsoring work in this area at Imperial College, London. A recent paper, "Using CIM to Realise Policy Validation within the Ponder Framework," describes the application of the research to the DiffServ policies in CIM.

To address the first of these problems, the potentially enormous number of policies, each managed element can be assigned one or more roles. Policies can then be associated with roles rather than individual elements. RFC3460 defines a role as follows:

A role is a type of attribute that is used to select one or more policies for a set of entities and/or components from among a much larger set of available policies.

Shakespeare said that "one man in his time plays many parts." Had he had the advantage of having read this book and RFC3460, he would have said that "one man in his time plays many roles." Sometimes he plays the role of father, at other times the role of taxi driver and at other times the role of barbecue chef. There might be policies appropriate to all fathers, another to all barbecue chefs.

A more useful example might relate to a company which has an IP network connecting its sites. In larger sites there might be separate telephony equipment (PBXs ^[5] ) and routers, but in smaller sites there might be devices combining the roles of PBXs and IP routers. This company might want to specify a policy relevant to all devices playing the part of an IP router, including both the dedicated routers and the PBXs acting as routers. There might be another policy relevant only to voice switching equipment. Another policy might be associated with both voice switching equipment and IP routers.

Were it not possible to associate a policy with a role, then it would have to be associated individually with each type of device, a much more time-consuming task.

I show part of the DMTF model dealing with Policy Roles in Figure 6.9. The class CIM_PolicyRoleCollection is an aggregation of CIM_PolicySets, each of which, as shown in Figure 6.8, is a CIM_Policy. CIM_PolicyRoleCollection has a property PolicyRole which is a string labelling the role (for example, "IP Routing") and must be associated with exactly one CIM_System.

Figure 6.9: Roles in the Policy Hierarchy

CIM_PolicyRoleCollection is a sort of clearing-house between CIM_ManagedElements and CIM_PolicySets: it says that a particular managed element may be subject to certain policies. Note the word "may." This is the power of roles ”they can be defined but not activated until triggered. To activate a particular policy, CIM_PolicyRole-Collection provides a method ActivatePolicySet() which, when invoked, creates an association, CIM_PolicySetAppliesToElement, directly between the Managed Element concerned and the Policy Set. A similar method, DeactivatePolicySet(), removes this association.

Summary of the Policy Model

A policy is simply a set of rules, each consisting of a number of conditions and associated actions.

 

The User Model

Like the Network Model, the User Model is very large and somewhat incomplete. Between version 2.7 and 2.8 of the CIM schema it has been significantly simplified; unfortunately the white paper (DSP0139) which describes it, has not (at the time of writing) been updated to reflect these changes. If you read DSP0139, then ignore references to the class CIM_UsersAccess (no apostrophe) which used to be pivotal and is now deprecated.

The User Model is about managing the users of a device: their names , addresses, credentials and authorities. Users in this sense are either humans or programs using the services provided by the device to be managed. The users of a PBX include those people who use telephones, those people who access their voice mail, those computers which connect to it to extract billing information, etc.

We can therefore expect to find the following concepts somewhere in the User Model:

• The concept of a user with a name, address, etc.

• The concept of an account which the user may have on a particular system; we would expect the account to be "weak to the system" in the sense described on page 68.

• The concept of some form of authentication to ensure that the user is who he says he is (anything from the knowledge of a password to a full DNA analysis).

• The concept of some form of authorisation saying what a particular user, once authenticated, may do.

As we review the User Model at high level in the remainder of this section, bear in mind that, as always in CIM, the model is about the management of things, not about their implementation. This is particularly true in the case of users ”the CIM system is not concerned about authenticating users and checking that they do not exceed their authority; it is concerned with managing the information that allows that authentication to take place. There is, of course, a related issue of ensuring that operators accessing the WBEM server itself are correctly authenticated and not allowed to do more than their authority permits . I describe this aspect of user management starting on page 142.

The Concept of a User

Of course, managing users is not new. Standards such as the ITU-T's X.500 have existed for a decade or more and contain lists of properties of users: title, surname , common name, street address, province or state, locality, country, organisation, etc. X.500 is considered to be too heavy for use in an enterprise and many of its features have been extracted into the Lightweight Directory Access Protocol (LDAP). LDAP is defined in a number of IETF RFCs; the complete list being contained in RFC3377. Note that, in spite of its name, LDAP does not just describe the protocol for accessing and updating user information; it also includes details of the properties that are typically exchanged.

When the designers of CIM's User Model came to define the class structure and properties of users they naturally made use of the work already done in X.500 and LDAP. This ensures compatibility with LDAP.

The details of the mapping of LDAP to CIM is described in the DMTF white paper number DSP0123, "LDAP Mapping Specification." Take, for example, the property "businessCategory." This is taken from standard X.520 and is defined in RFC2256 as follows:

 businessCategory This attribute describes the kind of business performed by an organization. ( 2.5.4.15 NAME 'businessCategory'   EQUALITY caseIgnoreMatch   SUBSTR caseIgnoreSubstringsMatch   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) 

This defines a property called businessCategory which is a string (believe it or not, "1.3.6.1.4.1.1466.115.121.1.15" means "string") of up to 128 characters . This maps into a property of the CIM_Person class:

 [MaxLen (128), Description (        "This property describes the kind of business "        "performed by an organization.") ]     string BusinessCategory; 

where the concept of a string is captured somewhat more succinctly by using the word "string."

There is one more important classification of users handled by the User Model. Users, particularly human ones, are gregarious and gather in groups: they are members of a department along with other people; they have a certain role in common with other people (e.g. System Administrator). Such groups can naturally be modelled within CIM as CIM_Collections (as described on page 95) and the membership relationship by the CIM_MemberOfCollection association.

A User's Identities and Accounts

There are two different views of user management:

1. The user looks at the system and asks, "Which parts of the system can I access?"

2. The system looks back at the user and says, "Who is this person, where is she, what are her credentials, can she prove that she's who she says she is?"

The User Model covers both of these viewpoints ”the former starting with an instance of CIM_UserEntity, the latter with CIM_Account and its close friend CIM_Identity.

CIM_Identity is really the centre of the authentication world ”it says that the owner of this identity has (or has not) had its credentials checked. Once the credentials are checked, it provides a level of trust and degree of access for the identified object.

As you can see from Figure 6.10, an identity, whether checked or not, can be associated with any CIM_ManagedElement through the CIM_AssignedIdentity association.

Figure 6.10: Part of the User Model

There is another class, CIM_Account, which also has aspects of verifying an identity, particularly a person's UNIX-style identity. In some respects, CIM_Identity and CIM_Account overlap and, had history been different, they would probably not exist as separate classes. As it is, they are closely associated by the CIM_AccountIdentity association.

Any user, and in particular a human user, a CIM_Person, can now have one or more associated identities (through instances of CIM_AssignedIdentity) and thereby an instance of CIM_Account (through CIM_AccountIdentity).

CIM_Account is a useful class to reach because it has associations, as illustrated in Figure 6.11, which connect it to a particular system. This completes the chain: the user has accounts of various types on various systems.

Figure 6.11: Users: The Chain of Associations

Authentication

The description so far has avoided the two crucial issues of authentication and authorisation: "Is this user who he says he is?" and "Is this user allowed to do this operation?"

Authentication can be thought of as a matter of policy: IF this user knows this password (or has that iris pattern in his right eye), THEN consider him authenticated. I have already mentioned (page 111) the CIM_AuthenticationCondition subclass of CIM_PolicyCondition. It is by satisfying the condition specified therein that a user becomes officially authenticated and gets the CurrentlyAuthenticated flag set in its instance of CIM_Identity.

Although performing the actual credential check is outside the scope of the WBEM management system, an authentication service (CIM_AuthenticationService) is defined (see Figure 6.12) and a significant part of the User Model is dedicated to classes representing credentials ” shared keys, public keys, biometrics, etc.

Figure 6.12: The AuthenticationService

One point should, however, be clear: the Boolean property CurrentlyAuthenticated on an instance of CIM _ Identity should generally not be writable by operators!

Authorisation

When a user is authenticated, he, she, or it is given certain privileges. Each privilege is described by an instance of the CIM_Privilege class. This contains information about the type of privilege (write access, read access, execute access) it affords to the user.

An instance of CIM_Privilege sits between a user's identity and a resource to which he has privileges ”see Figure 6.13. CIM_AuthorizedSubject is the link to the identity and CIM_AuthorizedTarget the link to the resource.

Figure 6.13: CIM_Privilege

Summary of the User Model

The User Model is designed to provide a set of classes, compatible where possible with LDAP, within which details of system users, their authentication mechanisms, and authority levels are stored.

 

^[3] OK, MPLS is really layer 2.5.

^[4] Toronto, by the way, is not the capital of Canada ”Ottawa is.

^[5] Private Branch eXchange: A small telephone exchange typically used within a building.