semi合集-English.pdf - 第3357页

SEMI E132-0305 © SEMI 2004, 2005 10 id Subject privilegeId Privilege ACLEntry Principal Role subject 1 1 PrivilegeAs s ignment RoleAssignment privileges 1 1..* principal 1 1 role 1 1 Figure 7 ACL Entry Description 11.2.4…

100%1 / 7923
SEMI E132-0305 © SEMI 2004, 2005 9
11 Authorization
11.1 Authorization Overview
11.1.1 Any client wishing to invoke privileged services on the equipment must be authorized to do so.
Authorization is implemented by granting access control privileges beforehand to defined clients and later checked
against the client’s requests. The total set of available privileges may include standardized service-level access
control, such as privileges to invoke specific services or functions, but may also include supplier-defined finer-
grained privileges. A default privilege to allow access to all services available from an authenticated session is
defined in this specification, and must be supported by all implementations. A user of the equipment therefore has
the option to reduce security enforcement on the equipment to authentication alone, achieved by assigning this all-
access privilege to all defined clients.
11.1.2 Figure 6 provides an abstract overview of the relationships among the Role, Principal, and Privilege concepts
defined in this specification. A Principal is either assigned to one and only one Role, or to one or more Privileges.
A Role is defined as a uniquely-identifiable set of 1 or more Privileges, and cannot be composed from other Roles.
Zero or more Principals can be assigned to at most one Role. These relationships are enforced through the
management of Access Control List entries, described in Section 11.2.
Privilege
Principal Role
0..* 1
role
0..*
1..*
privileges
0..*
1..*
privileges
{XOR}
Figure 6
Abstract Model of ACL
11.2 Access Control List
11.2.1 Access control privileges are assigned to defined clients (principals) by using an Access Control List (ACL).
An ACL is a collection of ACL entries, each entry granting a subset of the available privileges to a specific subject.
A subject can represent a specific principal, a uniquely-named role, or all principals that successfully authenticate
with the equipment. A principal can have privileges granted to it through either an explicit list of privileges, or
indirectly through assignment to a role. The equipment shall maintain the ACL defined in this specification in non-
volatile memory.
11.2.2 Roles are used to simplify the management of privilege assignments to principals. Each unique role has an
ACL entry that specifies the privileges assigned to that role. Those privileges can then be granted to principals
through a RoleAssignment ACL entry for each principal that should have those privileges. A principal must either
have a RoleAssignment or an explicit list of privileges assigned to it (PrivilegeAssignment); it is not permitted to
have both.
11.2.3 The equipment shall refuse session requests from clients that have no ACLEntry, either explicitly through a
role or privilege assignment, or implicitly through the existence of an ACLEntry for all authenticated principals.
SEMI E132-0305 © SEMI 2004, 2005 10
id
Subject
privilegeId
Privilege
ACLEntry
Principal
Role
subject
11
PrivilegeAssignment RoleAssignment
privileges1
1..*
principal
1
1
role1
1
Figure 7
ACL Entry Description
11.2.4 ACLEntry
11.2.4.1 Figure 7 shows the classes used for requesting the creation of a new ACLEntry on the equipment (see
Section 12.3.2.3). The ACLEntry is an abstract base class for the two kinds of ACL entries, PrivilegeAssignment,
and RoleAssignment. There can be only one ACLEntry for each subject. Attempts to add a second entry for same
subject shall generate a duplicate entry error (see Section 12.3.2.3). This class has no attributes or associations.
11.2.5 PrivilegeAssignment
11.2.5.1 This class defines an association between a given subject (either a Principal or a Role) and its set of
assigned privileges on the equipment. A PrivilegeAssignment for a Principal establishes all privileges that are
specifically granted to the Principal. A given Principal must either have a PrivilegeAssignment ACLEntry or a
RoleAssignment ACLEntry (see Section 11.2.6); it cannot have one (or more) of each. A PrivilegeAssignment for a
Role defines the role itself and the privileges that will be granted to any Principal that is assigned to that Role (see
Section 11.2.6). There can be only one PrivilegeAssignment ACLEntry for a given Role.
Table 8 PrivilegeAssignment Association Definitions
Association Role Name Definition Comments
subject The Principal or Role that is being granted privileges. One and only one element of any type
derived from Subject, described in
Section 11.2.7.
privileges The set of privileges being granted. List of one or more elements of type
Privilege, described in Section 11.2.10.
11.2.6 RoleAssignment
11.2.6.1 This class assigns a specific Principal to a Role. The identified Role must have a PrivilegeAssignment
ACLEntry elsewhere in the ACL. All privileges assigned to the identified Role are granted to the identified
Principal’s sessions. A given Principal must either have a RoleAssignment ACLEntry or a PrivilegeAssignment
ACLEntry (see Section 11.2.5); it cannot have one (or more) of each.
11.2.6.2 A PrivilegeAssignment ACLEntry for a Role cannot be deleted from the ACL until all Principals that were
assigned to that Role have been removed from it by deletion of their RoleAssignment ACLEntry. Any authenticated
sessions that were established for such Principals prior to the deletion of their RoleAssignment ACLEntry shall
continue to be operable with that Role’s privileges until the session is terminated. Subsequent attempts by such
SEMI E132-0305 © SEMI 2004, 2005 11
Principals to request sessions shall be rejected unless there is a default set of privileges assigned to the reserved
“anyPrincipal” (see Section 11.2.8). Otherwise, in order for session requests to be accepted, these Principals will
have to have specific privileges assigned to them directly through a PrivilegeAssignment ACLEntry, or indirectly
through assignment to a new Role.
Table 9 RoleAssignment Association Definitions
Association Role Name Definition Comments
principal The principal that is being assigned to the Role. One and only one element of type
Principal, described in Section 11.2.8.
role The Role to which the principal is being assigned. One and only one element of type Role,
described in Section 11.2.9. The Subject
id for the identified Role must be equal to
the Subject id of a PrivilegeAssignment
for a Role appearing elsewhere in the
ACL.
11.2.7 Subject
11.2.7.1 This is an abstract base class used to represent any entity that can be granted privileges in an ACL entry.
This can be either a Principal or a Role. The id is a text field that identifies a particular Subject. If the Subject is a
Principal, then the id is equal to that Principal’s unique id used during authentication. If the Subject is a Role, then
the id is equal to the name of the Role.
Table 10 Subject Attribute Definitions
Attribute Name Definition Form
id Identifies a Principal or Role. Text.
11.2.8 Principal
11.2.8.1 This class represents a specific Principal that can be authenticated and assigned privileges. This
specification defines a reserved Principal id that represents any Principal that successfully authenticates to the
equipment. The value of the id for this reserved Principal is “urn:semi-org:auth:anyPrincipal”. All implementations
shall support this reserved Principal. If an equipment user’s security policy permits the approach, a
PrivilegeAssignment or RoleAssignment ACL entry can be created for the reserved Principal to assign a default set
of privileges to any client that successfully authenticates, rather than creating an ACL entry for each Principal.
11.2.8.2 Each client that attempts to authenticate to the equipment must have an id that matches the id of one
PrivilegeAssignment or RoleAssignment ACLEntry for that Principal, or else there must be one
PrivilegeAssignment or RoleAssignment ACLEntry for the reserved “anyPrincipal”. If there are no such entries for
the authenticating client, the equipment shall reject the session request. If there is a PrivilegeAssignment or
RoleAssignment ACLEntry for both the specific Principal and the reserved “anyPrincipal”, the equipment shall
accept the session request, and shall grant only those privileges assigned to the specific Principal to the session.
Privileges assigned to the reserved “anyPrincipal” shall not be granted to such sessions.
11.2.9 Role
11.2.9.1 This class represents a Role that can be assigned privileges. Roles can simplify the assignment of
privileges to Principals. This is achieved by creating a single PrivilegeAssignment ACL entry for the Role
containing the appropriate privileges, and then assigning each Principal (or the reserved “anyPrincipal”) to that Role
using a RoleAssignment ACL entry.
11.2.10 Privilege
11.2.10.1 This class represents a specific privilege that can be granted to subjects as part of an ACL entry. All
defined privileges supported by the equipment can be obtained using the GetDefinedPrivileges operation of the
SecurityAdmin interface. How each privilege is applied to a subject is determined by the specification or equipment
supplier that defines the privilege. The privilege id is a text field that identifies a particular privilege and must be