Re: [scim] Is ServiceProviderConfig Required?

Phillip Hunt <phil.hunt@independentid.com> Wed, 13 October 2021 19:51 UTC

Return-Path: <phil.hunt@independentid.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 EDEE03A0CD2 for <scim@ietfa.amsl.com>; Wed, 13 Oct 2021 12:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20210112.gappssmtp.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 dF5WX0S3Ax8B for <scim@ietfa.amsl.com>; Wed, 13 Oct 2021 12:51:29 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 96AC43A0CCC for <scim@ietf.org>; Wed, 13 Oct 2021 12:51:29 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id t11so2537602plq.11 for <scim@ietf.org>; Wed, 13 Oct 2021 12:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3sNEmwu5GgQTdlXckUImipv03OmGQN+MhIfCu0aLo14=; b=oRdz7JNuEvwtmL5mLNBW54Ur8M4Vs9yMvg75AZy1FtljBSOPpVbgjVClY9klbAvwU0 f3o1xnjYuke0oxAa403I2AyJ+VODZBnWxipYBrVNnZVrU+WUi4bcC5TWtR8Hiy4vrgnV GQzsN4HeAvHb0sEesvbkfKQDfhPBJ9T9EuKYEAjDPjYFyXi9zoUPK++ABtNH/KbyS2K2 NfEPBJhj3VjEvDgx3utmXPTR9+82DI+GpmEUxtn96eJ0X4NN1KARupQcaYdcox7K1V4A 7Giw5g0H+4hPSN+e0+fuzsgiNvUoWb9EYeAgwSvLLYUiCxS4JXLfy93ebihkN1YAj7Bz xKrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3sNEmwu5GgQTdlXckUImipv03OmGQN+MhIfCu0aLo14=; b=8COY93MGeCOOkQGHuOO07CaveDKydYKXuLgWngC8mB07gvy3j+RbezczXcsvmfrTbl NKZRu6vkkp0GRpAl8vlXw77mQSK6k26fSz3Te8RaHVHj61IPlOsJ+OZcQHW2QQddtTIl bnJTGjPXBfSx28i5aW43dU/+A5Ul7M4QjSzL4rWxzNfamksUXVNl/WxLiASibLT+nTp1 TFd6/xqX9plKLYZ7hfgjm2nmUQzTmLeKtdL5dC+dThgpgGf1gZ1K59ZaXXvox7dEXGUw KCJFblK+GWr2fmMe5GIvbLPpZU+yHz4ZO1puCWU64110TxXJ4f0nHUUqT97q2UwJiZyL MYHQ==
X-Gm-Message-State: AOAM53053/UlOdwtLT5sv3BhTz+1VptK9k9nAIBeozCmmssPv0Es9O5m fUooYTeGUV50oaNzv2nKmzCYFw==
X-Google-Smtp-Source: ABdhPJxbcDXD94MQVyZ2a5tlpMZkwo2skDxeKxje6QsNRAe0JeSvP5AdV9B1Lpov98itVT/7LCjbbA==
X-Received: by 2002:a17:90a:10:: with SMTP id 16mr1448678pja.50.1634154688471; Wed, 13 Oct 2021 12:51:28 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qjhqzxo8nty10d3nkqo.ipv6.telus.net. [2001:569:7316:ae00:5cb4:1528:983c:3fc0]) by smtp.gmail.com with ESMTPSA id n207sm294183pfd.143.2021.10.13.12.51.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Oct 2021 12:51:28 -0700 (PDT)
From: Phillip Hunt <phil.hunt@independentid.com>
Message-Id: <2CBF0F69-D10A-4CE2-A0B5-8915B5634633@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_71FA66D8-E571-40FB-AB31-C2F0E019F972"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 13 Oct 2021 12:51:27 -0700
In-Reply-To: <20a7cfcb-5e00-6d5c-3629-b26328500cc4@pdmconsulting.net>
Cc: SCIM WG <scim@ietf.org>
To: Danny Mayer <mayer@pdmconsulting.net>
References: <9f90574b-aa33-4f06-209b-6281a3ab6600@pdmconsulting.net> <E45706C7-043E-41E8-A638-58AA452D11E4@independentid.com> <20a7cfcb-5e00-6d5c-3629-b26328500cc4@pdmconsulting.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Kxb4MgOmXmjY4UMlIZq6DO61Ve4>
Subject: Re: [scim] Is ServiceProviderConfig Required?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Oct 2021 19:51:35 -0000

Regarding SPC (ServiceProviderConfig)….we can certainly discuss this as part of the “discovery” features in the charter.  Just an FYI, its pretty non-trivial to change MAY to MUST in any spec. It would likely have to be part of an overall SCIMbis effort.

On the /Me stuff. I’m not seeing the problem. The only thing a SCIM server needs to know is how to map the credential to a scim resource.  Section 2 of RFC7644 discusses the required (MUST) need to map the client to an authorization policy that permits the action. For example, I believe PingIdentity uses a model evolved from LDAP ACIs as does i2scim.io (https://i2scim.io/AccessControl.html).

From RFC744 Section 2:

   Regardless of methodology, the SCIM service provider MUST be able to
   map the authenticated client to an access control policy in order to
   determine the client's authorization to retrieve and update SCIM
   resources.  For example, while a browser session may have been
   established via HTTP cookie or TLS client authentication, the unique
   client MUST be mapped to a security subject (e.g., User).  The
   authorization model and the process by which this is done are beyond
   the scope of this specification.

   When processing requests, the service provider SHOULD consider the
   subject performing the request and whether or not the action is
   appropriate given the subject and the resource affected by the
   request.  The subject performing the request is usually determined
   directly or indirectly from the "Authorization" header present in the
   request.  For example, a subject MAY be permitted to retrieve and
   update their own "User" resource but will normally have restricted
   ability to access resources associated with other Users.  In other
   cases, the SCIM service provider might only grant access to a
   subject's own associated "User" resource (e.g., for the purpose of
   updating personal contact attributes).


Phillip Hunt
@independentid
phil.hunt@independentid.com




> On Oct 13, 2021, at 9:45 AM, Danny Mayer <mayer@pdmconsulting.net> wrote:
> 
> Inline too!
> 
> On 10/13/21 11:57 AM, Phillip Hunt wrote:
>> Inline
>> 
>> Phil
>> 
>>> On Oct 13, 2021, at 8:24 AM, Danny Mayer <mayer@pdmconsulting.net> wrote:
>>> 
>>> I've been looking at some SCIM servers and it seems that some do not provide the ServiceProviderConfig endpoint and at least one Commercial SCIM Client didn't request the endpoint when I was testing it last year. Is it a requirement to provide this endpoint and is the client required to read it and obey the rules laid out in the returned information? Are clients using it?
>> ServiceProviderConfig is the standard way to do functionality, schema and resource type discovery.
>> 
>> As a discovery feature it is technically optional. It does seem silly not to implement it since for many its fairly simple to implement.
>> 
>> I have heard of many smarter clients that use it. I2scim.io client does discovery to defines its own schema to match.
> I think it should be REQUIRED to both implement and used. Having the client know what it can and cannot do seems to be essential especially as the client requests will be rejected (hopefully) if the client makes a request that it has already been told that it will not allow. Change Passwords come to mind as an example.
>>> I'm also not sure about the /Me endpoint. That requires that the SCIM server retain state. That should be the SCIM client's responsibility.
>> Not sure what you mean here. The server just uses the authorization header to locate what /Me refers to.  Eg matching username or sub claim.
> 
> That sounds dangerous from a security point of view. If an employee is able to make a call and authenticate themselves they could potentially change their own access permissions. On my SCIM Server implementation, only the authorized SCIM client was allowed to make any changes (and could not do it to their own account).
> 
> Danny
> 
>> 
>>> Danny
>>> 
>>> 
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>