feat: Integration test for verifying grant revocation#573
feat: Integration test for verifying grant revocation#573konac-hamza wants to merge 3 commits intoopenstack-experimental:mainfrom
Conversation
|
|
||
| use eyre::Result; | ||
| use tracing_test::traced_test; | ||
|
|
There was a problem hiding this comment.
please keep the spaces between import groups. First group is typically std (+ whatever is std nowadays like tracing, eyre), second group are the other foreign crates, 3rd are the own crates (i.e. when a project spreads across multiple crates, what in our case is going to be openstack_keystone_api_types, openstack_keystone_storage, etc). The last group are the imports from the current crate itself.
| access_rules: None, | ||
| name: Uuid::new_v4().to_string(), | ||
| project_id: "project_a".into(), | ||
| roles: vec![Role { |
There was a problem hiding this comment.
you should be having multiple roles. Explanation further down.
| .get_token_provider() | ||
| .encode_token(&post_revoke_token)?; | ||
|
|
||
| assert!( |
There was a problem hiding this comment.
intention with having multiple roles is to still have a working authentication just ensuring the revoked role is not present anymore.
|
|
||
| // CHECK 3: existing auth (issued before revocation) is no longer accepted | ||
| assert!( | ||
| matches!( |
There was a problem hiding this comment.
this shows the real problem and is exactly the purpose of the test. The token must be considered as a revoked and not that the user is not having roles. In the combination with having more roles initially this would lead to the vulnerability.
I am not sure why exactly, but we should get the TokenProviderError::TokenRevoked error
| use eyre::Report; | ||
| use sea_orm::{DbConn, entity::*}; | ||
| use std::sync::Arc; | ||
|
|
There was a problem hiding this comment.
same comment regarding the imports sorting is applicable here.
eedc423 to
95f5696
Compare
|
@gtema |
|
I was looking at it yesterday and found few issues:
|
|
it should be fine now to resolve the conflicts and update the test: there is a similar test verifying the revoke provider with the difference that it explicitly creates revocation event instead of revoking the concrete role and it does not verify the "auth" aspect like this test does |
Explain potential reason of the vulnerability
d5483ca to
8436997
Compare
| .is_ok(), | ||
| "Token should be valid before revocation" | ||
| ); | ||
| tokio::time::sleep(std::time::Duration::from_secs(1)).await; |
| !grant_exists(&state, &user.id, "project_a", "role_revoke_auth", true).await?, | ||
| "Grant should not exist after revocation" | ||
| ); | ||
| tokio::time::sleep(std::time::Duration::from_secs(1)).await; |
There was a problem hiding this comment.
add a comment here, that since token revocation is working with a seconds precision we need to wait for a new second before granting new token to prevent it being also eventually revoked
No description provided.