Service Connection Grant should contain Delegator ID when trying to connect with Services that are published using a Delegated Service Connection Grant
Situatie
Delegated Service Publication Grant
-
Sigmax biedt BRP namens Gemeente Stijns
-
Sigmax biedt BRP aan namens Gemeente Riemer
Service Connection Grant
Vergunningsoftware wilt verbinding maken met de BRP van Gemeente Stijns aangeboden door Sigmax
Problemen
- Sigmax kan geen twee Services met dezelfde naam (BRP) aanmaken. Dit is een probleem. Bij het aanmaken van Service moet de Delegator Peer ID ook opgegeven worden.
- Hoe maken we het onderscheid tussen BRP van Stijns en Riemer? Als ik een Contract binnen krijg met daarin een ServiceConnectionGrant dan vind ik in deze Grant terug: Mijn eigen PeerID (Sigmax), de naam van de Service(BRP) en het Outway Peer ID (Vergunningssoftware). Ik kan nu als Sigmax onmogelijk weten voor welke Service deze connection Grant bedoelt is.
- Komt alle informatie in de txlog? We zien in de txlog dat de BRP aangeboden wordt namens Gemeente Stijns. Dit lijkt dus goed te gaan.
- Punt 2 is ook van toepassing op DelegatedServiceConnectionGrants.
- Scenario: Sigmax biedt BRP namens Gemeente Stijns. Deze service is middels een Delegated Service Publication Grant gepubliceerd in de Directory. Client X heeft een Service connection grant met deze Service. Bij het intrekken van de Delegated Service Publication Grant door Gemeente Stijns, moeten Sigmax de Service Connection Grants ondertekenen met een 'revoke' handtekening. Anders blijft Client X toegang behouden tot de Service.
ADR scenario 5:
Het intrekken van een handtekening van een Delegated Service Publication zorgt er niet voor dat (Delegated) Service Connection Grants ondertekend worden met een 'revoke' handtekening. Het organiseren van het revoken van (Delegated) Service Connection Grants staat niet in de standaard beschreven en moet dus vooraf per scenario apart worden uitgedacht.
✅ 🌴 Mogelijke oplossingen: 💡
- Servicenamen in de Directory moet uniek zijn binnen een organisatie. (bv. Sigmax kan maar één BRP aanbieden)
- nadeel: we kunnen dit niet afdwingen / verplichten als er meerdere instanties van een Directory zijn. Want Sigmax zou een BRP kunnen aanbieden in Directory A van Group X en een BRP kunnen aanbieden in Directory B van dezelfde Group X. De check moet dus over de Directories heen plaatsvinden.
- De Delegator Peer ID opnemen in de (Delegated) Service Connection Grant.
- nadeel: dit zou de enige Peer ID zijn op een contract waarvan we geen handtekening verwachten.
- De Service Publication Grant opnemen in de (Delegated) Service Connection Grant.
-
nadeel: wat als het contract van de Service Publication Grant verloopt? Dat zou geen probleem mogen zijn, want je kan nog steeds de informatie uit het verlopen contract halen.
-
nadeel: als we voor deze optie kiezen dan moeten services verplicht worden gepubliceerd.
De oplossing
- Bij het maken van een (Delegated) Service Publication Grant moet je als organisatie zorgen dat je niet al een andere (Delegated) Service Publication Grant hebt die een Service met dezelfde naam aanbied.
Als Sigmax zelf een BRP aanbied met een Service Publication Grant, dan kan Sigmax niet een (Delegated) Service Publication Grant aanmaken die ook een BRP aanbied. Die BRP moet dan een andere, unieke, naam krijgen.
-
nadeel: we kunnen als netwerk niet afdwingen dat een Peer unieke services gaat aanbieden.
-
nadeel: hiermee is het probleem dat het delegator id kan worden gespoofed in het token nog steeds niet opgelost