Re: [scim] Groups Member Type

Shelley <randomshelley@gmail.com> Wed, 09 August 2017 21:59 UTC

Return-Path: <randomshelley@gmail.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C7213228D for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 14:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XZUWkhlT4MGG for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 14:59:33 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 223A4132195 for <scim@ietf.org>; Wed, 9 Aug 2017 14:59:33 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id w45so34027178uac.5 for <scim@ietf.org>; Wed, 09 Aug 2017 14:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=jBvU0fmtvdTj0xkgjCrscMGW9siJ5BeQHsu1Z6azwIi4z3av82hpWBZyP3+BT6pRGi cNpEscdHaLrDACEktGAOn71/WC9oAG9dMt56HHICZzbwl4eE3FBu0giwzr3xtnfJQ6C5 gk8IUdTVKGE+OgdGD20Q4cY4/f3buOiyN7appH0k/+KO58UlIsTTmPz+ItE3HCwV2I3b FXgf5IOPt8QFRKX7VBH9elrtU/NRT3aUGyzDmAEHUD5Rpy5VfrKyGw/E1KrpYI17Bjtl YU1foWsd8lguOHhnf4wrN6OW/dTTFBe4oMH2ivO2kFtFpDSYMOuPRAkw4N6pTYHzdbRy Co3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=OQjyhHIZGo8DMVHP5gRPZR+93cPhl0uOCk89JF5J8//1T1OUmIafWuR4e8QE3WZAdr ew7LDOD/C9HhQD3k0u4DHjg8aeo6aXX5CMhAF1AZ2PT7JJBeAZGtJ5hQEm+AWJnD2VnO YXxgzB6lwsbp21JIqXWGOt1JbQ37o1Tc+e1rgz2HbhVUYDeYTWp+lAoXxPLOIZPetRsE zb4zavf46fc1oISneQtEfQOBbfA/m3jrXlYusVaDY4UbnBXYp+hhmH66AX2FqKSnWCMJ ZDwtZV76/eTUBD/JSos7A4Ttn4JacB/Yg+18qKwuKuMG0zjWQjeaP4WMxR9dYKb5dRT3 exoA==
X-Gm-Message-State: AHYfb5hpb+cGmcAhumnRkLwatk/8foVYiQYV6g+BFhR5YfkNVUl8k+3o QwUFK7gYPG/2pn6MBXiLP1vy0Iqg5w==
X-Received: by 10.159.53.36 with SMTP id o33mr7212980uao.95.1502315972205; Wed, 09 Aug 2017 14:59:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 14:59:31 -0700 (PDT)
In-Reply-To: <CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0@CY1PR04MB2363.namprd04.prod.outlook.com>
References: <CAGUsYPz7_9Tat93aC2t=YAQcHG6dmboYDYij_8sRpKA6CZoWEA@mail.gmail.com> <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <CAGUsYPwUt997zV9sxC4p93Jz=9j+bWeqygyMSkssM1gMZfxhpQ@mail.gmail.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> <CAGUsYPyV7RjdmbUMcQ5N8NdwGjPzt2xHSANyNJon_uceNjhUgA@mail.gmail.com> <CAGUsYPzYh0zqpEedtAx2rwTKzPYRiURY3DTzJi8jyDUxrifUiw@mail.gmail.com> <CY1PR04MB2363D61AB4E1F0C5843904F5E28B0@CY1PR04MB2363.namprd04.prod.outlook.com> <BC21670B-1A93-430C-BBF7-0E1B5BE4B570@oracle.com> <CAGUsYPxTc-2Z0ifMNc2iY9xoyRXYLW46nrOtdJFw2VHUboXmcQ@mail.gmail.com> <CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0@CY1PR04MB2363.namprd04.prod.outlook.com>
From: Shelley <randomshelley@gmail.com>
Date: Wed, 09 Aug 2017 16:59:31 -0500
Message-ID: <CAGUsYPz+0DS9SZkzfPQFZaCeJU==AnGf4O2O-0h3UCCQZgvV-g@mail.gmail.com>
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c03ce80dd2006055659313e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/MDNLyLWWLd9BzOX5TETpw3ow8To>
Subject: Re: [scim] Groups Member Type
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 21:59:37 -0000

Thanks for the feedback.

*Now that it is being used as directory, closing some unspecified / loose
> areas might be better for interop IMO. *
>

Is it possible to fold some of these clarifications into the next SCIM RFC?


On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com>
wrote:

> Your plan sounds good to me, Shelly.  That’s how I would implement it.
>
>
>
> *From:* Shelley [mailto:randomshelley@gmail.com]
> *Sent:* Wednesday, August 9, 2017 1:42 PM
> *To:* Phil Hunt (IDM) <phil.hunt@oracle.com>
> *Cc:* Kelly Grizzle <kelly.grizzle@sailpoint.com>; scim@ietf.org
>
> *Subject:* Re: [scim] Groups Member Type
>
>
>
> *You can also tell via id which is local and $ref path given's scim's
> strict path rules (look at the parent of the last segment). *
>
>
>    - Is the id now required to be globally unique across all resource
>    types? If not, there is no *guarantee *that an SP can determine the
>    resource type from the id.
>    - The $ref is also optional, so this cannot be consistently used to
>    determine the type. Further, I was under the impression that the $ref
>    is primarily used for SPs to communicate the resource location to
>    consumers, rather than vice versa (i.e. it's essentially a *read-only*
>    attribute).
>
> Here is my tentative plan for our SP implementation for evaluating *group
> members*:
>
>    - Treat *value* as *REQUIRED*. While the example SCIM schema
>    <https://tools.ietf.org/html/rfc7643#page-69> does not actually
>    require the group member value sub-attribute, this is the most
>    consistent identifier for referring to members.
>    - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when
>    processing requests). Using a $ref provided by consumers seems a bit
>    fragile (aside from eliminating the complexity of URI comparison, it's
>    possible that a single resource may have multiple DNS names, which further
>    complicates absolute URI comparisons and integrity), and introduces
>    redundancy (and potential ambiguity) with value/type.
>    - Treat *type *as *OPTIONAL*. My *preference *would be to treat this
>    as REQUIRED in order to eliminate any ambiguity, but given that the SCIM
>    specs don't require it, doing this would limit interoperability for
>    consumers that may not be sending it.
>    - If *type *is not provided, assume the *default value is **"User"*.
>    - Perform *referential integrity *to ensure that any provided group
>    member resources exist, based on value and type.
>
> *Examples*
>
> Given the existence of the following resources, here are some example
> requests/responses based on this proposal:
>
>    - ../Users/abc
>    - ../Groups/xyz
>
>
>
> *Group Members*
>
> *Response*
>
> "members": [
>
>   {
>     "value": "abc",
>
>     "type": "User"
>
>   },
>
>   {
>
>     "value": "xyz",
>
>     "type": "Group"
>
>   }
>
> ]
>
> *2xx* - Success
>
> "members": [
>
>   {
>
>     "value": "abc"
>
>   },
>
>   {
>
>     "value": "xyz",
>
>     "type": "Group"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "abc",
>
>     "$ref": "anything at all"
>
>   },
>
>   {
>
>     "value": "xyz",
>
>     "type": "Group",
>
>     "$ref": "anything at all"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "xyz"
>
>   }
>
> ]
>
> *400 *- Missing “Group” "type" on nested group member definition
>
> "members": [
>
>   {
>
>     "value": "xyz"
>
>     "$ref": "../Groups/xyz"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "$ref": "../Users/abc"
>
>   }
>
> ]
>
> *400 *- Missing "value" on group member definition
>
> "members": [
>
>   {
>
>     "$ref": "../Groups/xyz"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "abc",
>
>     "type": "Group"
>
>   }
>
> ]
>
> *400 *- Wrong "type" provided
>
> "members": [
>
>   {
>
>     "value": "xyz",
>
>     "type": "User"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "abc",
>
>     "type": "UnsupportedType"
>
>   }
>
> ]
>
> *400 *- Unsupported "type" provided
>
> "members": [
>
>   {
>
>     "value": "no such resource with or without type"
>
>   }
>
> ]
>
> *400 *- Member does not exist
>
>
>
>
>
> On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <phil.hunt@oracle.com>
> wrote:
>
> I agree the server can decide.
>
>
>
> IMO the server should check referential integrity. By doing so it would
> likely know the type. The spec is silent (as far as i recall) on whether it
> expresses it.
>
>
>
> You can also tell via id which is local and $ref path given's scim's
> strict path rules (look at the parent of the last segment).
>
> From my recollection some of these items were not that important given
> scim was provisioning api for apps - apps implementing server side are free
> to do what they can/want. Now that it is being used as directory, closing
> some unspecified / loose areas might be better for interop IMO.
>
>
> Phil
>
>
> On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com>
> wrote:
>
> Given the general desire for SCIM to allow loose reading but strict
> writing, I would vote for option 1.  If type is not specified in a
> PUT/POST/PATCH then the server can assume “User”.
>
>
>
> --Kelly
>
>
>
> *From:* Shelley [mailto:randomshelley@gmail.com <randomshelley@gmail.com>]
>
> *Sent:* Wednesday, August 9, 2017 9:02 AM
> *To:* Kelly Grizzle <kelly.grizzle@sailpoint.com>
> *Cc:* scim@ietf.org
> *Subject:* Re: [scim] Groups Member Type
>
>
>
> *Resurrecting this old thread, as this question has recently come up
> during some of our interoperability testing, and there still appears to be
> some ambiguity in the spec...*
>
>
> The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected
> behavior if the type sub-attribute is not provided on a Group resource
> member. Neither spec seems to explicitly require this attribute, so what
> is the expected behavior if no type is provided? Is there a default (e.g.
> "User" or "Group"), must Service Providers search for the member across *all
> *resource types, or should it be treated as REQUIRED (e.g. returning a 400
> error)?
>
>
>
>
>
> On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.com> wrote:
>
> Thanks, Kelly. Given that the ID may represent either a User or Group and
> only the combination of "type" and "value" uniquely identify the reference,
> should the canonical "type" attribute for group members be REQUIRED as
> well? (Further, the majority of examples throughout the Protocol
> specification only include a "value" and not "type", so it's ambiguous as
> to whether these "values" represent Users or Groups.)
>
>
>
> On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <
> kelly.grizzle@sailpoint.com> wrote:
>
> I opened ticket #35 to change this.
>
>
>
> http://trac.tools.ietf.org/wg/scim/trac/ticket/35
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_scim_trac_ticket_35&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=azLSrYlOBRiSWZ3BiA7nEnSujz0OPCep2bx8PeAdobE&e=>
>
>
>
> --Kelly
>
>
>
> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf
> Of *Shelley
> *Sent:* Monday, February 11, 2013 11:36 AM
> *To:* Kelly Grizzle
> *Cc:* scim@ietf.org
> *Subject:* Re: [scim] Groups Member Type
>
>
>
> +1 to mark it as "immutable".
>
> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com>
> wrote:
>
> Good point.  It seems like this should say “immutable” rather than
> “read-only”, since it can be set initially but not updated.  Thoughts from
> anyone else?  If this seems reasonable I’ll open an issue to get this fixed.
>
>
>
> --Kelly
>
>
>
> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf
> Of *Shelley
> *Sent:* Friday, February 01, 2013 1:37 PM
> *To:* scim@ietf.org
> *Subject:* [scim] Groups Member Type
>
>
>
> As indicated in Section 8, the canonical types for Group members are
> READ-ONLY. As such, how can consumers provide the type (i.e. "User" or
> "Group")? Is it implied that IDs are unique across both users and groups in
> order for service providers to fulfill this requirement?
>
>
>
>
>
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_
> ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=
>
>
>