[I2nsf] Post 3: Differentiating between Groups and Roles
John Strassner <strazpdj@gmail.com> Sun, 20 December 2015 07:39 UTC
Return-Path: <strazpdj@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE71B2A60 for <i2nsf@ietfa.amsl.com>; Sat, 19 Dec 2015 23:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgtk-TxVEIDW for <i2nsf@ietfa.amsl.com>; Sat, 19 Dec 2015 23:39:30 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292CE1B2A5F for <i2nsf@ietf.org>; Sat, 19 Dec 2015 23:39:30 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id p203so95952285lfa.0 for <i2nsf@ietf.org>; Sat, 19 Dec 2015 23:39:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OYK9qAsXDIPVaSYpalFQxYPGmu8cd5OdUW1C2lHi5EE=; b=HNhKekrY/xSEu3oN/o3g6e+chdwhAf/lHT98Ud7Ox9MhvKugXJo+zLgfE78o05WjQx O0AuPtAkfgWu09+1ZlArIsR0DhgG0nUxNqidjBsjhnUSFEEN53rGSxaZ2/wxzEX5Jr8O Zhn4AG7+Lx2CSYDrxrOEDKeNrIJ603EOvYYlFxjsbnM78bhi9P1G1xqTGhE5XuiKDHu2 h8J5Ky5+il2szsHboCbFHNVF5/X1rP95KhbPYSJggbEP9xjN9pLb0zQtCN+9nwpOzNvo RSBax/19K7nl0y06cNxfTChSX9IQczuQok/HbG74iQXSv9FA6N1LlV7GE42JqtsPcLgn UT8g==
MIME-Version: 1.0
X-Received: by 10.25.156.73 with SMTP id f70mr4420402lfe.70.1450597168300; Sat, 19 Dec 2015 23:39:28 -0800 (PST)
Received: by 10.25.143.206 with HTTP; Sat, 19 Dec 2015 23:39:28 -0800 (PST)
Date: Sat, 19 Dec 2015 23:39:28 -0800
Message-ID: <CAJwYUrEbXAOGRQQNpcfH3YNb-XA-51W697+rUDq0AWPDU=0=uQ@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: i2nsf@ietf.org
Content-Type: multipart/alternative; boundary="001a114017c6edce7905274f78ac"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/B6QYNRzRkgwzI_zonBePTGzdkVg>
Subject: [I2nsf] Post 3: Differentiating between Groups and Roles
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Dec 2015 07:39:34 -0000
During IETF94, I expressed discomfort with the "Subject-Object-Action-Function" paradigm. This note defines and differentiates between the concepts of groups and roles. 1. Motivation There are several places in draft-merged-i2nsf-framework-04 that treat groups and roles as the same. I feel that this is incorrect. For example: "However, the notion of Groups (or roles), ..." "Composite Groups or Roles (I2NSF-Role)...This is a group of..." There are also places where role is used (correctly imho) but which contradict the implied equivalence of groups and roles, such as: "to reflect the different roles that each vNSF is designated for" 2. Definitions The mathematical treatment of groups is important, as it more clearly differentiates groups from roles. 2.1. Group A group is a set of elements. Mathematically, a group G is defined with an operation O. When O is applied to any two elements of the group, a and b, the result is a third element c, that is part of G. More specifically, G and O must satisfy the following four axioms: - Closure: For all a, b in G, a O b is also in G - Associativity: For all a, b, c in G, (a O b) O c = a O (b O c) - Identity: There exists an element e in G such that e O a = a O e = a - Inverse: For any element a in G, there exists an element b in G, such that a O b = b O a = e (the identity element) 2.2. Role In software engineering, a role is defined as a responsibility that an object has. Since a responsibility may be complex, the responsibility is represented as an object. This has the additional advantage of making it reusable. For example, in a business, it is common to group people into a number of different roles. A role may be restricted by context (e.g., by time, location, or other factors). An object may be able to combine roles (technically called a role combination), such as an EmployeeRole AND a SupportDeskRole AND a ManagerRole. If this is done, then it is important to ensure that the responsibilities of the roles in the role-combination do not conflict with each other (e.g., if an Employee submits a travel document for reimbursement, then that same Employee MUST NOT be able to sign the same document; more formally, this is called separation of privileges, and the Principle of Least Privilege is often a cornerstone of security implementations [2]). 2.3. Role-Object Pattern This is a fundamental design pattern, and is described more thoroughly in [1]. Its purpose is to adapt an object O to the needs of different clients through a set of transparently attached role objects R. In this approach, each role object R represents a role that O has to play in that particular client's context. The key feature in this simple design pattern is the use of **context**. For example, a user may have multiple roles (i.e., responsibilities) assigned, such as an engineer and a manager. Each role may have different permissions, and in general, roles may or may not be allowed to be used concurrently. This pattern models context-specific functionality of an object O as a set of role objects R that can be dynamically attached to, and removed from, the object O. This allows the combination of O and R to be viewed as an **aggregate object** that represents **one** logical object (even though it consists of multiple separate objects). In UML, this is represented as an **aggregation**. Visually, the pattern looks like this: +--------+ HasRoles +------+ | Object |<>---------->| Role | +--------+1..1 0..n+------+ where the HasRoles relationship is an aggregation. Its multiplicity means that an Object may have zero or more Roles, but each Role is defines for that particular object. In this design, the Role class is subclassed to define the different types of Roles that this object can play. The aggregation then enables zero or more of these roles to be selected based on context. 3. Why Group Is NOT The Same As Role Looking at the definitions above, a Group is "just" a set. Furthermore, there are specific properties of a Group that guarantee a set of behaviors that characterize group operation. In stark contrast, a Role has nothing to do with sets. A role represents a single responsibility that the object has. Roles are, of course, related to the object that aggregates them, but the concepts of closure, identity, and inverse are not applicable. More importantly, the concept of associativity is NOT true, as this can lead to privilege violation. 4. Using Groups and Roles Since these are different concepts, they can be easily combined. Consider the following UML diagram: +----------------------+ | PersonOrOrganization | +----------+-----------+ / \ I I +--------+-------------------+ I I I I +-------+------+ HasPeople +------+-------+ | |<>----------->| | | Organization | | Person | | | | | +---+------+---+ +--+--------+--+ I / \ / \ I I \ / \ / I I | | I Org | | Person Subclasses | | Subclasses | | \ / \ / +-----+---+ +-----+------+ | OrgRole | | PersonRole | +---------+ +------------+ The above figure shows: 1) An organization with a set of subclasses 2) A Person with its own set of subclasses 3) An Organization with an aggregation of OrgRole subclasses 4) A person with an aggregation of PersonRole subclasses 5) An aggregation, enabling an Organization to aggregate People Hence, any of the Organization subclasses can have its own Role or Role Combination, and any of the Person classes can have their own separate Role or Role Combination. 5. References [1] Riehle, D., "Composite Design Patterns", Proceedings of the 1997 Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA '97), ACM Press, 1997. Page 218-228 [2] http://csrc.nist.gov/groups/SNS/rbac/standards.html regards, John
- [I2nsf] Post 3: Differentiating between Groups an… John Strassner