/Schemas reports readonly attributes as readWrite

[gsar]

Our scim_attributes_map has several attributes that can only be read (no foo= accessor for writing) however this is not being reflected in the output of /Schemas, making it a bit useless for auto-discovery.

[pond]

@gsar A question about this one. The endpoint describes the schemas and so is currently nice and simple; it reports the SCIM specification schemas, or a custom schema.

A custom schema's mutability descriptions of attribues should obviously match the actual mutability of the mapped attributes. Meanwhile, the RFC schema would surely require the specified mutability to be obeyed. The server shouldn't have to worry about a non-standard client, just sending what it wants to send to that client with the client mapping or dropping attributes as it sees fit.

I can't see anything in the RFCs stating that a standard schema attribute described as readWrite is actually optionally mutable and might be read-only - but I might be wrong about that. I'd be prepared to put the (significant) work in to rewrite the Schemas endpoint to read the attribute map and override the schema definitions, but only if we can find a good RFC reason for doing so. Otherwise, just add write accessors that ignore the value.

[gsar]

@pond some SCIM implementations out there are capable of reading the /Schemas endpoint to determine what features of SCIM are supported. i tried to get this working with Microsoft's implementation but couldn't. some sections of the doc there suggest clients can try to discover the schema, so it would be great to have a way for /Schemas to report what is actually implemented (as opposed to what's in the standard). maybe it is easier to do this with configuration instead of the code trying to automatically figure it out? that would be sufficient, i think.

relevant section of the RFC says this about things marked readWrite: MAY be updated and read at any time, so adding an accessor that ignores the modification (as opposed to raising) would make it a non-compliant implementation.

[pond]

@gsar As I think about implementation here, questions arise.

• I don't think I want to add even more declarations. We've got the Schema classes already, but then an additional scim_attributes_map and, actually, a lot of the time Scimitar isn't using the Schema stuff at all but just goes via the map. Adding a third way to declare attributes to override the schema would be confusing!

• In that case we'd prefer to iterate via the schemas, find an associated resource class, look up its attribute map and work on assumption that a lack of write accessor -> readonly, a lack of read accessor -> writeonly. But it would probably do that only for things which the schema said were read-write; if the standard says something is read- or write-only, I don't think I'd want to second guess and override that with read-write just because the target model appears to have a mapped attribute that contains a bidirectional accessor.

• Let's say that's good enough, and lack-of-writer -> readonly, but now we have trouble for attribute mappings of things like emails, since (at least with an ActiveRecord back-end) those tend to vary their written attribute according to type, with the attribute map holding an array of entries (phone numbers are similar). So let's say we map to work_email_address and home_email_address, and only one of those has a write accessor - what do you say about emails.value's mutability in the schema? "It depends"...

Perhaps the way forward is something that you do to override the underlying schema itself, actually updating its predefined attribute map in the Scimitar initializer. That feels a bit like adding a third kind of declaration LOL but kinda not, it's more modifying the out-of-box schema config in some reasonable way.

[gsar]

@pond broadly agree with your "bottom-line" assessment. /Schemas endpoint should render based on the same attribute map that is being used as the source of truth to handle requests.

[pond]

@gsar How does https://github.com/RIPAGlobal/scimitar/pull/135 look?

[pond]

Gone ahead with this and published it as v2.9.0 (Rails 7) and v1.10.0 (Rails 6).