Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings
Atul Tulshibagwale <atultulshi@google.com> Tue, 14 July 2020 16:50 UTC
Return-Path: <atultulshi@google.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1533A0A64 for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 09:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 scQJqPWoAjht for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 09:50:23 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 004613A08C0 for <id-event@ietf.org>; Tue, 14 Jul 2020 09:50:22 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id y13so8475085ybj.10 for <id-event@ietf.org>; Tue, 14 Jul 2020 09:50:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CnMdbdxhDVYg9UAx5bSrYOMQl3v2NaxKcpA/3O91iDE=; b=WcF7FjN4pQFofH3cvFWG1VyHuZyLd1FPRA5NwPtZ2fX6T2EDpgzWcPMPO0cHlIglwN ErQqy1kXIE9mxpRKUEU5pZkYK0WSKc3me6B3XBOhwKJPrNR4/LhnAMBnNzGE74EwRSZ9 G3/MDNwsjLfQp9RioamNzgHV4orq0LdObi6su+H6ls2JeGO9LLlWoisGJZsLP36j6Dsf UpCn8FfDQWCnkm+RLHhtL2gEledOTnDGghDIaR7WYemQOdRhCG2RZPg+JKhHsToLB/gZ wzxUZ/WEaiXprep7uJlaL7zZGPlbQVnzoILOO9DzxpRnqzuNm2/4ZFhwLj058swjH0zD 67wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CnMdbdxhDVYg9UAx5bSrYOMQl3v2NaxKcpA/3O91iDE=; b=mRrYT1wd6iIQl6x7pZ3/tSnxWaBJ/KJnJ/m5nqrZTQdlgfDCKrxsxcZBqYKjFSOQ8H +JYfI65ThnkBNxPzrOdJyBgABtmJgZ9qeiNSlPSNNFD5jlun2HGfZEAULOaXKPsPTiUx jjZlNTSsncycenATDI22Uik/CLrpWDkg0Pc4FYSvBMYSBEVXSeNclgnBZ/R8PkQSVJUB fX/mnYlMq2xYfar5lmO5rMI+CBKqFzn22qvRdOhGAMAMx0jr2MDbZ32Qe//OVL2HTXEm mQeo8vYr001A7Z0ZXYZt808EV3TPcxd51y2K4A8g8kFt+YjNm/mzGneDbaJF8jNTsVzF y9jQ==
X-Gm-Message-State: AOAM531eSa4Nd+rBhHFFhJ1jToUXxj3xfT2Y2LnPYEDKtFTXcaraEHCW LGcL9FP3GEwqHmOUweIRsjBtmwhR9z+03Z4Vi19fxA==
X-Google-Smtp-Source: ABdhPJynWPIs0wmLSyU9hd6fdyIwUKUtQ7UlvyiAiX8+cmlfpJ41JKwy/4NX80gs+RRtG1mrhT0jkTnXjHOwwVtWqC8=
X-Received: by 2002:a25:3155:: with SMTP id x82mr9331201ybx.492.1594745421561; Tue, 14 Jul 2020 09:50:21 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR00MB067812E3F5D58E5B1F029137F5610@CH2PR00MB0678.namprd00.prod.outlook.com> <CAD9ie-s_b-vfUMhaOQz23C27_6eA6Cd-KeVjvh7HBgD1TTdByg@mail.gmail.com>
In-Reply-To: <CAD9ie-s_b-vfUMhaOQz23C27_6eA6Cd-KeVjvh7HBgD1TTdByg@mail.gmail.com>
From: Atul Tulshibagwale <atultulshi@google.com>
Date: Tue, 14 Jul 2020 09:50:10 -0700
Message-ID: <CAMCkG5s_42ZGFF4OrMr4et8a4eHvj5hyTbnssPmCB4FP9KG6NA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, SecEvent <id-event@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c89e905aa699a17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/qeVrCwG6NW38tKx2AhKvRmCmQZk>
Subject: Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 16:50:26 -0000
That's how I was thinking about it too. It's a property of the subject, so it could be a part of the subject-identifier. On Tue, Jul 14, 2020 at 9:32 AM Dick Hardt <dick.hardt@gmail.com> wrote: > Well ... that was not quite what I was saying :) ... but it is another > question to ask. I would lean towards it being a subject modifier (a > property of the subject object) rather than somewhere else. > > On Tue, Jul 14, 2020 at 9:25 AM Mike Jones <Michael.Jones@microsoft.com> > wrote: > >> I agree with Dick that a key question is whether the SPAG belongs in the >> event or in the subject identifier. >> >> >> >> Note that this specification could still define a SPAG for inclusion in >> SET events, even though its primary purpose is defining subject identifiers >> for use in SETs. >> >> >> >> -- Mike >> >> >> >> *From:* Dick Hardt <dick.hardt@gmail.com> >> *Sent:* Tuesday, July 14, 2020 8:56 AM >> *To:* Atul Tulshibagwale <atultulshi@google.com> >> *Cc:* Mike Jones <Michael.Jones@microsoft.com>; SecEvent < >> id-event@ietf.org> >> *Subject:* Re: [Id-event] Subject Principals and Subject Principal >> Administrative Groupings >> >> >> >> Hi Atul >> >> >> >> If the SPAG has value in the event message, then it should be specified. >> >> >> >> I was proposing that the SPAG be determined at the transport layer rather >> then the event/message layer. >> >> >> >> An advantage of being in the event is that it is independent of >> transport. In a multi-tenant situation, where different components do >> different parts of the processing, and the original transport is no longer >> available, the SPAG would be always available rather than wrapping the >> event to include the SPAG. >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Jul 14, 2020 at 7:55 AM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> A few points / responses: >> >> 1. Agree with Mike that spag_id should not be a required claim unless >> it's actually required for every subject. So keeping it optional (if we >> decide to have it at all) is the right thing to do. >> 2. IMO it will be far simpler for multi-tenanted hosts to use SPAGs >> rather than manage multiple event streams (i.e. one per tenant) >> 3. A multi-tenanted architecture is increasingly very common, so this >> will apply to a large number of organizations. >> 4. For single tenanted transmitters, the SPAG id may be inferred by >> receivers. Single tenanted receivers may ignore the SPAG ids in the >> subjects. So processing SPAGs in hybrid situations does not appear to be >> cumbersome. >> 5. The use of SPAGs is not limited to tenant-level information, since >> it may be applied to OUs or groups >> 6. If we agree that SPAG is a "meta concept" that applies in most >> situations, then capturing it in the spec is probably important. What Dick >> is proposing is a way to implement SPAGs without specifying them in a >> standard, so each entity is free to define it the way they want. This >> approach can cause incompatibilities. >> 7. Without SPAGs in the spec, if peers need to send events about >> SPAGs, then they need to use the "iss-sub" catch all to send events about >> enabling or disabling events about SPAGs. Since this is not standardized, >> it could also cause proprietary and incompatible implementations. >> >> Atul >> >> >> >> On Mon, Jul 13, 2020 at 5:23 PM Mike Jones <Michael.Jones@microsoft.com> >> wrote: >> >> As I see it, the use cases that require a spag_id can use them when >> necessary (unless the working group decides on another way to do this) but >> I certainly would oppose requiring it when it’s unnecessary. >> >> >> >> -- Mike >> >> >> >> *From:* Id-event <id-event-bounces@ietf.org> *On Behalf Of *Dick Hardt >> *Sent:* Monday, July 13, 2020 5:13 PM >> *To:* Atul Tulshibagwale <atultulshi@google.com> >> *Cc:* SecEvent <id-event@ietf.org> >> *Subject:* Re: [Id-event] Subject Principals and Subject Principal >> Administrative Groupings >> >> >> >> Would different URLs for each relationship not solve your issue of >> maintaining secrets for each SPAG? For example: >> >> >> >> https:/example.com/secevent/SPAG_ID_1 >> >> >> >> https:/example.com/secevent/SPAG_ID_2 >> >> >> >> https:/example.com/secevent/SPAG_ID_3 >> >> >> >> Then the credential is independent of the SPAG, but we are not injecting >> an identifier (spag_id) that is only relevant to orgs that want to use the >> same credentials across SPAG relationships. >> >> >> >> >> >> >> >> On Mon, Jul 13, 2020 at 5:08 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> I am OK with making the spag_id a required claim in every subject >> identifier. For single tenanted transmitters, it would be a constant value >> for all events they generate. >> >> >> >> On Mon, Jul 13, 2020 at 4:01 PM Dick Hardt <dick.hardt@gmail.com> wrote: >> >> So the receiver is using authentication sometimes to determine SPAG, and >> not at other times? >> >> >> >> I'm digging into this as I had always thought of the event being between >> two parties, where they are identified by the endpoint and/or the >> credentials. >> >> >> >> Adding a relationship identifier seems to be solving the problem at the >> wrong layer, unless it is in all events. >> >> >> >> >> >> On Mon, Jul 13, 2020 at 3:54 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> Sorry for the terse message. >> >> >> >> If a single tenant transmitter is trusted by a multi-tenanted receiver >> for a specific tenant, then the SPAG-id need not be included if the subject >> is unique at the tenant level, because the receiver will automatically >> identify SPAG that the subject belongs to on its end (based on the >> authentication). >> >> >> >> >> >> >> >> On Mon, Jul 13, 2020 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote: >> >> Which part is not required? >> >> >> >> On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> Not required, since the claim is optional. >> >> >> >> On Mon, Jul 13, 2020 at 3:25 PM Dick Hardt <dick.hardt@gmail.com> wrote: >> >> Would a transmitter that is only in one SPAG (a single tenant system) >> have to include its SPAG id in events sent to a receiver that accepts >> events from multiple SPAGs? But it would not include it in sending events >> to other receivers that have separate credentials for each relationship? >> >> >> >> >> >> >> >> ᐧ >> >> >> >> On Mon, Jul 13, 2020 at 3:05 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> That could be true but there are a few ways in which it can be avoided: >> >> 1. The peers leverage some higher-level trust to accept / decline >> events relating to lower level SPAGs. For example, if trust is established >> at a tenant level, then an OU level SPAG need not have its own >> authorization. >> 2. The secret required for establishing the authorization of a SPAG >> may be temporary. For example: >> >> >> 1. An administrator signs in to their tenant in the transmitter's >> administrator console >> 2. The admin obtains a temporary authorization (one-time code) >> 3. The admin signs in to their tenant in the receiver's >> administration console and pastes in the one-time code >> 4. The receiver sends a request to enable the stream for the >> specified SPAG with that one-time authorization. >> >> In the first case, there are no additional secrets required. In the >> second case, the secret is temporary. >> >> >> >> >> >> >> >> On Mon, Jul 13, 2020 at 2:34 PM Dick Hardt <dick.hardt@gmail.com> wrote: >> >> I see the SPAG lets the transmitter and receiver provide context, as the >> subject identifier may be the same across SPAGs. >> >> >> >> Now I'm trying to understand how the transmitter authenticates to the >> receiver if it does not have it's own secret (assuming that authentication >> model) -- IE, how does the receiver know the transmitter is authorized for >> that SPAG? >> >> >> >> >> >> On Mon, Jul 13, 2020 at 2:08 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >> Dick, your understanding is correct. >> >> >> >> To clarify the proposal here, Here's the text I'm proposing to be added: >> >> >> 3. Subject Principals >> >> Subject Principals are the management entities associated with >> Subjects. These may be human or robotic principals or devices or >> other entities that are managed by transmitters and receivers. For >> example, the same Subject Principal may be referred to by an email >> address or a phone number. A transmitter or receiver will typically >> manage subject principals and organize them into sub-groupings such >> as tenants, groups, organizational units, etc. >> >> Subjects are identified by Subject Identifiers defined below. >> >> 3.1. SPAGs >> >> Subject Principals MAY be grouped for administrative purposes into >> "Subject Principal Administrative Groupings" or SPAGs. For example, >> all users belonging to one customer of a "multi-tenanted" Transmitter >> may be in one SPAG. Alternatively, an Organizational Unit or a group >> of Subjects within a customer of a Transmitter (whether multi- >> tenanted or not) may be one SPAG. SPAGs may have overlapping sets of >> Subjects. >> >> A SPAG MAY be the Subject of certain stream update events defined >> later in this spec, hence is defined as a Subject Type of its own >> below.. A SPAG identifier MAY be included in other subject types to >> disambiguate the subject. >> >> A SPAG subject identifier is agreed to offline between a transmitter >> and a receiver. >> >> The benefits of doing this are: >> >> 1. Multi-tenanted hosts do not need to maintain secrets per tenant >> and per transmitter tenant if each tenant has to be an event transmitter >> and an event receiver of its own. >> 2. An event stream may be established between two multi-tenanted >> hosts, and so does not need to be managed at a per-tenant level >> 3. The same subject or subject principal may be a part of multiple >> SPAGs, and identifying the SPAG that an event relates to can be achieved if >> the standard allows for the SPAGs to be identified. >> >> >> >> >> >> On Mon, Jul 13, 2020 at 11:32 AM Dick Hardt <dick.hardt@gmail.com> wrote: >> >> To clarify, your proposal is driven by the implementation burden of >> maintaining separate secrets / streams between a transmitter and receiver? >> >> ᐧ >> >> >> >> On Mon, Jul 13, 2020 at 9:01 AM Atul Tulshibagwale <atultulshi= >> 40google.com@dmarc.ietf.org <40google.com@dmarc..ietf.org>> wrote: >> >> Hi all, >> >> Here's a quick background for the proposal >> <https://github.com/richanna/secevent/pull/1> for including Subject >> Principals and Subject Principal Administrative Groupings or SPAGs in the >> Subject Identifiers spec. >> >> >> >> *Use of Subject Identifiers in Shared Signals and Events*: >> >> The Shared Signals and Events (SSE) profile of SETs specifies that >> transmitters and receivers send and receive SETs that contain Subject >> Identifiers. These subject identifiers have the format that is now being >> discussed as a separate specification here. >> >> >> >> *Transmitters and Receivers in SSE* >> >> The SSE profile defines transmitters and receivers as hosts that manage >> streams between peers. The receiver authenticates to the transmitter using >> OAuth, requiring the use of a secret per receiver. In a multi-tenanted host >> that handles hundreds of thousands or millions of independent tenants, >> maintaining such a secret per instance of a receiver is cumbersome. >> Furthermore, since a transmitter and a receiver has to maintain a stream >> per pair, creating such per-tenant streams can add significant >> implementation overhead. >> >> >> >> *SPAGs* >> >> Therefore, we need a notion of a grouping of subjects within the same >> transmitter and receiver to distinguish between various administrative >> groupings that exist within a host. These groupings could include tenants, >> organizational units or user groups.. This grouping is captured in the >> notion of a SPAG. The uniqueness of a user identifier (subject identifier) >> may also be limited to a SPAG. For example, if a random unique ID >> represents a user, then that ID may be unique within a SPAG and not >> universally across a transmitter or receiver. This is because each >> transmitter and receiver may have multiple connections to other >> transmitters and receivers, and ensuring uniqueness across all such peers >> is probably an intractable problem. >> >> >> >> *Subject Principals* >> >> While what is represented within a subject identifier may be only an >> aspect of the management entity, the administrative grouping is about the >> management entity itself. This could be the user, device or other principal >> that the subject identifier represents. Therefore, an abstract notion of a >> Subject Principal is also required in order specify what the grouping >> within a SPAG is about. >> >> >> >> The above is captured in the "Subject Principal" and "SPAG" sections >> within the proposed PR <https://github.com/richanna/secevent/pull/1>. >> >> >> >> Thanks, >> >> Atul >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >>
- [Id-event] Subject Principals and Subject Princip… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Mike Jones
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Phil Hunt
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Mike Jones
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale
- Re: [Id-event] Subject Principals and Subject Pri… Tim Cappalli
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Mike Jones
- Re: [Id-event] Subject Principals and Subject Pri… Dick Hardt
- Re: [Id-event] Subject Principals and Subject Pri… Atul Tulshibagwale