Re: [scim] Setting a mutability value such as readOnly or readWrite for whole SCIM resources

Hans-Joerg Happel <happel@audriga.com> Fri, 09 December 2022 17:52 UTC

Return-Path: <happel@audriga.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 42767C13B4E2 for <scim@ietfa.amsl.com>; Fri, 9 Dec 2022 09:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGSMnzjuxiVZ for <scim@ietfa.amsl.com>; Fri, 9 Dec 2022 09:52:05 -0800 (PST)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343BAC1522AA for <scim@ietf.org>; Fri, 9 Dec 2022 09:52:05 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 3C8FCA22D; Fri, 9 Dec 2022 18:52:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxYykpzjK09E; Fri, 9 Dec 2022 18:51:59 +0100 (CET)
Received: from [192.168.10.147] (ip-109-090-161-242.um36.pools.vodafone-ip.de [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 21168A0FF; Fri, 9 Dec 2022 18:51:59 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------hRlYZcqx00XSlwkKwkhzA9bI"
Message-ID: <9ba1e9ec-4415-e104-77dd-bba29787d024@audriga.com>
Date: Fri, 09 Dec 2022 18:51:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
Content-Language: en-US
To: Phillip Hunt <phil.hunt@independentid.com>
Cc: scim@ietf.org
References: <621ed78f-5071-cff5-3d5a-92446647f22e@audriga.com> <3CC40FEB-2F7D-41EF-ADB7-B96B98D21F15@independentid.com>
From: Hans-Joerg Happel <happel@audriga.com>
In-Reply-To: <3CC40FEB-2F7D-41EF-ADB7-B96B98D21F15@independentid.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/96Ke_5KR7AqOWJS5ZKGvLOvMGNg>
Subject: Re: [scim] Setting a mutability value such as readOnly or readWrite for whole SCIM resources
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 09 Dec 2022 17:52:09 -0000

Hi Phil,

thanks your elaboration! The approach you describe seems basically the 
"workaround" we're currently using.

However, this does not seem to be ideal for me.

One use case for us is to manage domains in a PostfixAdmin service via 
SCIM [1], where it should be possible to read and probably write (if the 
service is configured to allow that) domains (Danny wrote a draft for a 
very similar use case, in which domains are read-only [2]. I was talking 
to him to probably extend his draft to include our requirements as well).

My problem with the HTTP error solution (or "workaround") is that a 
software calling the PostfixAdmin SCIM service would need to attempt 
writing/POSTing a domain at least once, in order to find out if this is 
supported by the server.

In our case, the software might be an admin user interface or control 
panel. I would consider it a bad user experience to let an admin first 
try to provide data and try create a domain which eventually might fail 
then.

Instead, the software should be able to identify if a certain resource 
is writable (e.g., using "mutable" property), so that, e.g., the 
creation of domains can be prohibited/disabled in the interface.

Does that make sense for you?

Thanks and best,
Hans-Joerg

[1] https://github.com/audriga/postfixadmin-scim-api
[2] 
https://datatracker.ietf.org/doc/html/draft-zollner-scim-domain-extension-00

On 08.12.22 19:57, Phillip Hunt wrote:
> Hans,
>
> If I understand your case (resource mutability), it can be handled 
> with access controls  in order to determine if/when a client may 
> update a particular resource or resource type. As with LDAP 
> specifications of the past and the wide variance of 
> access/authoriztion in http services, the SCIM specs are silent on how 
> access policy is defined/managed.
>
> Per Sec 3.12, SCIM follows the HTTP specs for signalling errors (e.g. 
> 403 Forbidden).  In the error response payload (shown at the end of 
> 3.12) you could give a detail value that indicates mutability as the 
> reason for the 403.  The issue here is that most clients would ignore 
> the detail response.  Still its useful if a support person is trying 
> to figure out why the operation is failing.
>
> Attribute mutability in the spec is defined because it does impact the 
> overall protocol.  For example on a PUT, a readOnly value is ignored, 
>  On a GET and writeOnly value (e.g. password) is never returned.
>
> Hope this helps!
>
> Phillip Hunt
> phil.hunt@independentid.com
>
>
>
>
>
>> On Dec 8, 2022, at 9:25 AM, Hans-Joerg Happel <happel@audriga.com> wrote:
>>
>> Hi,
>>
>> RFC 7643 allows to define a "mutability" to SCIM resource attributes 
>> to express if a certain attribute is, e.g., readOnly, readWrite, or 
>> writeOnly.
>>
>> We've some cases where we would like to have a "mutability" value 
>> assigned to whole SCIM resources instead of attributes only (This 
>> might also be a relevant feature in the light of the discussion at 
>> the recent SCIM interim about multiple different SCIM "actors" 
>> interacting).
>>
>> As far as I see, this is not possible based on the current spec. So 
>> some workaround for an SCIM endpoint right now might just be to 
>> return some error code on HTTP level [2], if, e.g., a request tries 
>> to write a resource which cannot be written for some reason.
>>
>> However, perhaps I am missing something here?
>>
>> Otherwise, this might be a candidate for a rfc7643bis. Is there 
>> already a place where we track issues for those?
>>
>> Thanks and best,
>> Hans-Joerg
>>
>> ps.: In addition, the (im)mutability of  SCIM "service provider 
>> configuration" endpoints (/ServiceProviderConfig, Schemas and 
>> /ResourceTypes) seems to be rather implicitly specified currently 
>> (https://datatracker.ietf.org/doc/html/rfc7644#section-4) "SCIM 
>> defines three endpoints to facilitate discovery of SCIM service 
>> provider features and schema that MAY be retrieved using HTTP GET:"
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc7643#section-2-2
>> [2] https://datatracker.ietf.org/doc/html/rfc7644#section-3.2
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>