|
|
Post by AMI_Mani on Nov 28, 2022 15:28:38 GMT
Hi,
Assume Read only/Operator privilege user creates 3 sessions like below
/redfish/v1/SessionService/Sessions/1
/redfish/v1/SessionService/Sessions/2
/redfish/v1/SessionService/Sessions/3
When user give get request using basic auth of read only/Operator privilege to /redfish/v1/SessionService/Sessions, it will list below 3 active sessions
/redfish/v1/SessionService/Sessions/1
/redfish/v1/SessionService/Sessions/2
/redfish/v1/SessionService/Sessions/3
If user give get request using session auth of id 1(/redfish/v1/SessionService/Sessions/1), it has to list only one session
/redfish/v1/SessionService/Sessions/1
It should not show other two active sessions(/redfish/v1/SessionService/Sessions/2, /redfish/v1/SessionService/Sessions/3) since it's from different session.
Please confirm if above behaviour is correct since I'm unable to find details related to SessionsCollection response based on Session authentication.
If any details available in Specification, Schema related to this please point to me
Thanks,
Mani
|
|
|
|
Post by mraineri on Nov 28, 2022 15:46:08 GMT
We have the following statement in the Redfish Specification (in the "Redfish service operation-to-privilege mapping") clause that allows for additional handling as needed. You can reduce the set of members returned and fine-tune the response for URIs if needed to enforce additional restrictions (such as preventing read-only user "Bob" from viewing sessions of other users).
A service may perform additional checks based on the identity of the user and remove data from responses. For example, a service might restrict access for non-administrative users to only access their own ManagerAccount, Session, and EventDestination resources.
|
|
|
|
Post by mrrobert on Jan 10, 2023 4:05:35 GMT
Hi mraineri,
I wonder about the difference between basic authorization and x-access-token.
For example, I create 3 new sessions by a ReadOnly account:
/redfish/v1/SessionService/Sessions/1 --> retrieve the x-access-token in response payload from this creation.
/redfish/v1/SessionService/Sessions/2
/redfish/v1/SessionService/Sessions/3
Query the SessionCollection in 2 cases:
- GET /redfish/v1/SessionService/Sessions with basic authorization (ReadOnly username and password)
- GET /redfish/v1/SessionService/Sessions with authorizing by x-access-token (got from creation above).
The ReadOnly Account has Login privilege and SessionCollection allows GET for Login privilege also.
So I assume the responding of above 2 query cases should be the same: List all 3 created by ReadOnly account.
Is that correct?
Thanks
|
|
|
|
Post by mraineri on Jan 10, 2023 17:42:24 GMT
If the same ReadOnly user created all three sessions, then yes, I would expect those three members to be returned in the response to both GET requests.
However, if session 1 was created by ReadOnly user "Bob", and the other two were created by ReadOnly users "Fred" and "Alice", then when Bob performs a GET on the session collection (with either Basic Auth or the X-Auth-Token), only session 1 would be returned (ideally).
|
|
|
|
Post by shawn on Jan 11, 2023 0:57:20 GMT
If the same ReadOnly user created all three sessions, then yes, I would expect those three members to be returned in the response to both GET requests. However, if session 1 was created by ReadOnly user "Bob", and the other two were created by ReadOnly users "Fred" and "Alice", then when Bob performs a GET on the session collection (with either Basic Auth or the X-Auth-Token), only session 1 would be returned (ideally). I think, ideally, it should only return their own data if the user is a non-administrative user. I just wonder if it really does so, won't it break the definition from "Entity": "SessionCollection" in redfish.dmtf.org/registries/v1/Redfish_1.3.0_PrivilegeRegistry.json? Or the implementation should modify the privilege registry as well if it does this ideal way? Like {
"Entity": "SessionCollection",
"OperationMap": {
"GET": [
{
"Privilege": [
"Login", "ConfigureSelf"
]
}
],
...
}, |
|
|
|
Post by mraineri on Jan 11, 2023 1:36:24 GMT
Yes, exactly; if the user is non-administrative, they will only see their own sessions.
However, when considering this from the top-level HTTP operation perspective, ALL users can perform a GET operation on the session collection and can see a "Members" property. It's up to the service to fine-tune the list in "Members" based on the user performing the request, and unfortunately that specific nuance is not really possible to describe in the registry without a lot of extra complexity. This is why we have the "A service may perform additional checks based on the identity of the user and remove data from responses." statement in the spec since it's not obvious from the registry itself.
|
|
|
|
Post by shawn on Jan 11, 2023 2:14:16 GMT
Got it. That makes sense. It's hard to describe it in the registry indeed.  Thanks. |
|
|
|
Post by AMI_Mani on Jan 31, 2023 14:29:10 GMT
We have below information as per earlier comments
A service may perform additional checks based on the identity of the user and remove data from responses. For example, a service might restrict access for non-administrative users to only access their own ManagerAccount, Session, and EventDestination resources.
In this case based on non-administrative user sessiontoken passed in request, service can return only that session in session collection instead of returning all sessions created by non-administrative user.
Please confirm whether above is valid based on service implementation
Thanks,
Mani
|
|
|
|
Post by mrrobert on Feb 1, 2023 2:22:30 GMT
I think, if non-administrative user (Bob) creates multiple sessions (e.g. 3), there are 2 cases here:
- If we use Bob's sessiontoken passed in request, all created sessions of Bob should be responded in SessionCollectin(same as passing Bob's username/password in request)
- If we use another non-administrative user (Alice) in request, service only return sessions which created by Alice.
The main point here is what difference between using sessiontoken and username/password to authorize the request.
|
|
|
|
Post by mraineri on Feb 2, 2023 15:56:28 GMT
I think, if non-administrative user (Bob) creates multiple sessions (e.g. 3), there are 2 cases here: - If we use Bob's sessiontoken passed in request, all created sessions of Bob should be responded in SessionCollectin(same as passing Bob's username/password in request) - If we use another non-administrative user (Alice) in request, service only return sessions which created by Alice. The main point here is what difference between using sessiontoken and username/password to authorize the request. You're correct in the desired behavior. There isn't a difference in terms of using a token instead of a username/password; the response payloads would be the same. The only difference is purely internal with regards to verifying the user's request against a valid token or set of known credentials. In the case of Bob providing one of their session tokens, the service would map that token back to the user Bob, much like a username/password pair would also map back to user Bob. |
|
