Authorization of an organization trying to subscribe to generic events is currently being done based on their party id. This works fine if the policy for the resource contains party id for the subjects with access, but making rules with party id is difficult for people outside Altinn. The party id is primarily internal to Altinn. It is exposed here and there, but we want to avoid forcing the people creating these policies to do that lookup.
We should be able to authorize access to generic events for resources with rules that lists specific organisation numbers in their policy.
This change should not remove support for party id. That would be a breaking change. This issue focus on the ability to handle orgNo as a Consumer value during push.
We're starting with the Authorization logic for push. Authorization for the GET endpoint already support orgNo.
[ ] The logic in XacmlMapperHelper.CreateSubjectAttributes must be able to handle a consumer containing an organisation number and create a matching Attribute.
Acceptance Criteria
[ ] A subscription with a consumer of type orgNo is getting generic events pushed
[ ] A subscription with a consumer of type partyId is still getting generic events pushed
Push generic event to organization consumer ✅
push app event to organization consumer ❓
Push generic event to party consumer out of scope
push app event to party consumer out of scope
Description
Authorization of an organization trying to subscribe to generic events is currently being done based on their party id. This works fine if the policy for the resource contains party id for the subjects with access, but making rules with party id is difficult for people outside Altinn. The party id is primarily internal to Altinn. It is exposed here and there, but we want to avoid forcing the people creating these policies to do that lookup.
We should be able to authorize access to generic events for resources with rules that lists specific organisation numbers in their policy.
This change should not remove support for party id. That would be a breaking change. This issue focus on the ability to handle orgNo as a Consumer value during push.
We're starting with the Authorization logic for push. Authorization for the GET endpoint already support orgNo.
Rule from resource ttd-altinn-events-automated-tests in at23:
Tasks
XacmlMapperHelper.CreateSubjectAttributes
must be able to handle a consumer containing an organisation number and create a matching Attribute.Acceptance Criteria