HP Model 755/125cL HP-UX DMI 2.0 Developer's Guide: HP-UX/HP 9000 Computers, - Page 30

Group-Level Security

Get HP Model 755/125cL - Workstation PDF manuals and user guides View all HP Model 755/125cL manuals
Add to My Manuals
Save this manual to your list of manuals

Page 30 highlights

Component Interface Concepts Group-Level Security Original Definition (scalar) Group-Level Security HP provides a group-level security mechanism for its implementation of DMI 2.0. In order to use this security feature, the management application and the component instrumentation developers must agree to not ship the security libraries separately. Furthermore, executables using this security feature statically link to the security libraries. Intel recommends this type of security and it must be enforced by the component instrumentation developer. The following sections describe how to implement group-level security. The description is derived from the paper DMI 2.0 Security Token Proposal written by Brodi Beartusk and John Keith of Intel Corporation. Modifying Groups to Use Security Tokens Component instrumentation supporting this group requires that management applications provide the Security Token attribute when making a call. This attribute is passed on as the keylist for the operation. Applications not in possession of the Security Token can not access any attributes in the group. Component instrumentation denies access to applications that request the first row of the group. In order to secure a scalar group, you must first convert it to a tabular group by adding a Security Token attribute to the group definition, then specify this attribute as the key attribute for the group. The following example shows how to redefine the scalar System Memory Group as a tabular group with a Security Token. Start Group Name = "System Memory Group" Class = "HP|System Memory Group|001" ID = 2 Start Attribute Name = "Total Physical Memory" ID = 1 Type = int64 Access = Read-Write Storage = Specific Value = 0 End Attribute End Group 30 Chapter 3

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
30
Chapter 3
Component Interface Concepts
Group-Level Security
Group-Level Security
HP provides a group-level security mechanism for its implementation of
DMI 2.0. In order to use this security feature, the management
application and the component instrumentation developers must agree
to not ship the security libraries separately. Furthermore, executables
using this security feature statically link to the security libraries.
Intel recommends this type of security and it must be enforced by the
component instrumentation developer.
The following sections describe how to implement group-level security.
The description is derived from the paper DMI 2.0 Security Token
Proposal written by Brodi Beartusk and John Keith of Intel
Corporation.
Modifying Groups to Use Security Tokens
Component instrumentation supporting this group requires that
management applications provide the Security Token attribute when
making a call. This attribute is passed on as the keylist for the
operation. Applications not in possession of the Security Token can not
access any attributes in the group. Component instrumentation denies
access to applications that request the first row of the group.
In order to secure a scalar group, you must first convert it to a tabular
group by adding a Security Token attribute to the group definition, then
specify this attribute as the key attribute for the group. The following
example shows how to redefine the scalar System Memory Group as a
tabular group with a Security Token.
Original
Definition
(scalar)
Start Group
Name = "System Memory Group"
Class = "HP|System Memory Group|001"
ID = 2
Start Attribute
Name = "Total Physical Memory"
ID = 1
Type = int64
Access = Read-Write
Storage = Specific
Value = 0
End Attribute
End Group