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

[Hans-Joerg Happel <[e-mail]>]

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
> [e-mail]
>
>
>
>
>
>> On Dec 8, 2022, at 9:25 AM, Hans-Joerg Happel <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
>