Checked for duplicates
Yes - I've already checked
🐛 Describe the bug
In get_awskeys_from_cognitojwt.py, the Lambda function get_role_arn_for_group (line 109) iterates over a user's Cognito groups and returns the first group that has a RoleArn associated with it. This creates a problem for nodes (specifically SBN) that have users in multiple Cognito groups tied to different registry indexes.
SBN has two organizations (UMD and PSI) with separate Cognito groups, each mapped to a different IAM role and registry index. When a user belongs to both PDS_SBN_UMD_USERS and PDS_SBN_PSI_USERS, the function returns whichever role ARN appears first — which may not correspond to the registry index the user is attempting to write to.
The COGNITO_ALLOWED_GROUPS check at line 70 correctly uses any(...) to allow users in any permitted group, but the downstream role resolution assumes one group → one role → one registry index, which breaks for multi-org nodes.
🕵️ Expected behavior
When a user belongs to multiple Cognito groups, the Lambda should select the role ARN that corresponds to the specific registry index being accessed, not simply the first group that has a role. The role selection should be based on the target registry index or some explicit user-provided context (e.g., a request header indicating which org/index is the target).
📜 To Reproduce
- Create a Cognito user that is a member of two groups, each mapped to a different IAM role (e.g., a UMD group and a PSI group for SBN)
- Attempt to write to the PSI registry index using credentials that resolve to the UMD role
- Observe that the write either fails (wrong IAM permissions) or silently writes to the wrong index
🖥 Environment Info
- Version of this software: current main branch
- File:
terraform/applications/lambda/src/get_awskeys_from_cognitojwt.py
- Operating System: N/A (Lambda function)
📚 Version of Software Used
Current main branch
🩺 Test Data / Additional context
Root cause: get_role_arn_for_group at line 109 returns on the first group with a RoleArn, with no awareness of which registry index is the intended write target.
Proposed fix: The request should include context about the target registry index (e.g., a header or query parameter specifying the node/org). The Lambda then selects the role ARN for the group whose index matches the requested target, rather than defaulting to the first group found.
This is the sibling issue to NASA-PDS/data-upload-manager#384, which addresses the same multi-group problem in the DUM ingress authorizer.
🦄 Related requirements
For Internal Dev Team To Complete
⚙️ Engineering Details
🎉 Integration & Test
Checked for duplicates
Yes - I've already checked
🐛 Describe the bug
In
get_awskeys_from_cognitojwt.py, the Lambda functionget_role_arn_for_group(line 109) iterates over a user's Cognito groups and returns the first group that has aRoleArnassociated with it. This creates a problem for nodes (specifically SBN) that have users in multiple Cognito groups tied to different registry indexes.SBN has two organizations (UMD and PSI) with separate Cognito groups, each mapped to a different IAM role and registry index. When a user belongs to both
PDS_SBN_UMD_USERSandPDS_SBN_PSI_USERS, the function returns whichever role ARN appears first — which may not correspond to the registry index the user is attempting to write to.The
COGNITO_ALLOWED_GROUPScheck at line 70 correctly usesany(...)to allow users in any permitted group, but the downstream role resolution assumes one group → one role → one registry index, which breaks for multi-org nodes.🕵️ Expected behavior
When a user belongs to multiple Cognito groups, the Lambda should select the role ARN that corresponds to the specific registry index being accessed, not simply the first group that has a role. The role selection should be based on the target registry index or some explicit user-provided context (e.g., a request header indicating which org/index is the target).
📜 To Reproduce
🖥 Environment Info
terraform/applications/lambda/src/get_awskeys_from_cognitojwt.py📚 Version of Software Used
Current main branch
🩺 Test Data / Additional context
Root cause:
get_role_arn_for_groupat line 109 returns on the first group with aRoleArn, with no awareness of which registry index is the intended write target.Proposed fix: The request should include context about the target registry index (e.g., a header or query parameter specifying the node/org). The Lambda then selects the role ARN for the group whose index matches the requested target, rather than defaulting to the first group found.
This is the sibling issue to NASA-PDS/data-upload-manager#384, which addresses the same multi-group problem in the DUM ingress authorizer.
🦄 Related requirements
For Internal Dev Team To Complete
⚙️ Engineering Details
🎉 Integration & Test