HP Visualize c160L HP-UX DMI 2.0 Developer's Guide: HP-UX/HP 9000 Computers, - Page 51

MI Security

Get HP Visualize c160L - Workstation PDF manuals and user guides View all HP Visualize c160L manuals
Add to My Manuals
Save this manual to your list of manuals

Page 51 highlights

Management Interface Concepts MI Security MI Security DMI does not provide primitives to own or lock resources over a sequence of commands. Multiple management applications may make simultaneous accesses to the interfaces. Grouping and scheduling of operations, other than the synchronization provided by the DMI SP, are the responsibility of the management application. Likewise, any desire for mutual exclusion to lock out certain accesses or to provide DMI database security in any form is the responsibility of the management application. The HP-UX implementation of DMI 2.0 stresses the need to protect attribute values. The attribute names do not require protection as they do not provide useful information. There are three levels of security for the HP-UX implementation of DMI 2.0. These are: • Group-level security provided by the component developer. • Machine list protection; • User name check on HP-UX clients; These levels are described in the following sections. Group-Level Security For detailed information on group-level security, see Group-Level Security in the Component Interface Concepts chapter. Intel recommends this type of security and it must be enforced by the component instrumentation developer. Access to protected attribute values requires a Security Token. Group level security requires that the Component Instrumentation developer and the management application developer agree on a Security Token. HP provides a library with a Security Token-generating procedure and a Security Token validation procedure. Additionally, HP provides a library to management application writers that wish to retrieve protected attributes from HP's implementation of the Unix Standard Groups Definition. This library also has the Security Token generating procedure. Chapter 7 51

  • 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
Chapter 7
51
Management Interface Concepts
MI Security
MI Security
DMI does not provide primitives to own or lock resources over a
sequence of commands. Multiple management applications may make
simultaneous accesses to the interfaces. Grouping and scheduling of
operations, other than the synchronization provided by the DMI SP, are
the responsibility of the management application. Likewise, any desire
for mutual exclusion to lock out certain accesses or to provide DMI
database security in any form is the responsibility of the management
application.
The HP-UX implementation of DMI 2.0 stresses the need to protect
attribute values. The attribute names do not require protection as they
do not provide useful information.
There are three levels of security for the HP-UX implementation of
DMI 2.0. These are:
•
Group-level security provided by the component developer.
•
Machine list protection;
•
User name check on HP-UX clients;
These levels are described in the following sections.
Group-Level Security
For detailed information on group-level security, see Group-Level
Security in the Component Interface Concepts chapter.
Intel recommends this type of security and it must be enforced by the
component instrumentation developer.
Access to protected attribute values requires a Security Token. Group
level security requires that the Component Instrumentation developer
and the management application developer agree on a Security Token.
HP provides a library with a Security Token-generating procedure and
a Security Token validation procedure.
Additionally, HP provides a library to management application writers
that wish to retrieve protected attributes from HP's implementation of
the Unix Standard Groups Definition. This library also has the Security
Token generating procedure.