|
|
Post by dmitry on Jan 22, 2020 10:23:19 GMT
Hi Everyone,
The Redfish session login process as being described in sections 13.3.1 and 13.3.4.3 of the Redfish specification (1.8.0 revision) allows unauthenticated POST request to the "/redfish/v1/SessionService/Sessions" resource.
This contradicts with the information contained in the Redfish_1.0.4_PrivilegeRegistry.json where POST method against the SessionCollection entity is mapped to "Login" privilege assuming authorization being accomplished. The "NoAuth" privilege corresponding to a non-authenticated request seems the correct value in this case.
Could someone comment if I miss something.
Thanks,
Dmitry
|
|
|
|
Post by dmitry on Jan 22, 2020 12:12:48 GMT
And one more interesting thing about the privilege registry is that operation maps for some entities which (according to the CSDL schema) do not to support some methods (e.g. POST, DELETE) still contain mapped privileges for those operations.
This is just an observation, these discrepancies actually shouldn't cause implementation problems.
|
|
|
|
Post by jautor on Jan 27, 2020 19:25:53 GMT
Hi Everyone, The Redfish session login process as being described in sections 13.3.1 and 13.3.4.3 of the Redfish specification (1.8.0 revision) allows unauthenticated POST request to the "/redfish/v1/SessionService/Sessions" resource. This contradicts with the information contained in the Redfish_1.0.4_PrivilegeRegistry.json where POST method against the SessionCollection entity is mapped to "Login" privilege assuming authorization being accomplished. The "NoAuth" privilege corresponding to a non-authenticated request seems the correct value in this case. Could someone comment if I miss something. Thanks, Dmitry
I believe you're correct and that is a bug in the PrivilegeRegistry. I'll confirm that with the group and reply after our meeting this week.
Jeff
|
|
|
|
Post by dmitry on Jul 13, 2021 9:45:28 GMT
Hi everyone, as of 1.1.0 revision of the privilege registry, it still requires the Login privilege to post/start a new session.
|
|
|
|
Post by jautor on Jul 15, 2021 19:39:14 GMT
Sorry! We did discuss this last year, but I forgot to come back to this thread and post a reply.
The group concluded that this is not a bug, and no matter what we do here the POST to the SessionCollection is an exception case that has to be recognized and handled by the service. The difference here is that the authentication is provided in the body of the request, not with an Auth header.
Also, the Privilege Registry that the DMTF publishes is just an example, so if it makes sense for your implementation to remove the Login privilege so that it works better for your implementation / web framework, that's perfectly fine.
Jeff
|
|
