When the /Me endpoint is implemented, PUT / POST / PATCH / DELETE should be supported

[fflorent]

Quoting the RFC7644 on page 10:

Resource Endpoint         Operations             Description
 -------- ---------------- ---------------------- --------------------
  [...]

   Self     /Me              GET, POST, PUT, PATCH, Alias for operations
                             DELETE (Section 3.11)  against a resource
                                                    mapped to an
                                                    authenticated
                                                    subject (e.g.,
                                                    User).

I guess it would be fine to propose these operations. What do you think?

I can take a look at it when I have time if you want to.

[fflorent]

Something that is unclear to me at the moment is this paragraph in section 3.11:

When using the SCIM Create Resource command (HTTP POST) with the
"/Me" alias, the desired resourceType being created is at the
discretion of the service provider, based on the authenticated
subject (if not anonymous) making the request and any request body
attributes (e.g., "schemas"). See Section 7.6 for information on
security considerations related to this operation.

I understand that submitting a POST /Me request should trigger a resource creation. If that makes sense for an anonymous user, it looks awkward to me when authenticated the user doesn't work on themselves… which is inconsistent regarding the semantic). Maybe differ this subject in another issue and return a 501 (NOT IMPLEMENTED) status code so we can at least implement the rest?

[sleelin]

Hi @fflorent,
I'm transferring this issue over to the scimmy-routers repository, and will address it there, as this is where SCIM routes are actually defined.

Thanks,
Sam

[sleelin]

Hi @fflorent, apologies for the delay in properly addressing this!
In RFC7644§3.11 the /Me endpoint is defined as being one of: not supported, redirecting to the canonical resource location, or processing the requests directly.

The current approach taken by scimmy-routers is to blur this definition slightly and process GET requests directly, whilst responding with 501 Not Implemented for POST/PUT/PATCH/DELETE requests.

In theory it should be straightforward to implement handling for the other requests, however it raises a whole plethora of other considerations that are very much out of scope of scimmy and scimmy-routers, including:

• Potentially/inadvertently facilitating undesired anonymous user creation (POST),
• Possible authenticated user privilege escalation (PUT/PATCH)
• Accidental deletion of authenticated user (DELETE)

Granted these issues would only exist for poorly secured implementations (i.e. when there's no verification that a given request is authorised before it goes ahead), it still seemed prudent to minimise this risk. I suppose it would be possible to implement the remaining methods behind a configuration value (something like directMe or completeMe or similar?) that is disabled by default, so as not to introduce these issues unless explicitly opted into?

Let me know what you think.

Thanks,
Sam

[fflorent]

Hi @sleelin,

My turn for apologizing answering you with delays.

Thank you for your feedback. Indeed, there are questions to address before enabling these endpoints.

Your point of view totally makes sense. My issue was more in a "comply with the standard" mindset rather than asking for answering a particular need.

I close this ticket, regarding my need. Feel free to reopen it if you would like this question remain open.

Thank you for your valuable work!
Florent