Verenigingsinformatie met overheden delen en hergebruiken zorgt voor meerwaarde bij vereniging én betrokken overheden door:

• Efficiëntie: door informatie te delen, hebben alle overheden toegang tot betere gegevens en wordt het onderhoud eenvoudiger.

• Automatisch hergebruik: bekende verenigingsgegevens kunnen direct worden hergebruikt zonder extra navraag (bijvoorbeeld bij het aanmaken van een dossier).

• Directe updates: nieuwe informatie van verenigingen is meteen beschikbaar voor alle overheden.

• Minder administratie: niet langer verenigingen periodiek bevragen aangezien updates automatisch worden gedeeld door alle overheidsinstanties.

• Transparantie: verenigingen kunnen de gegevens die de overheid over hen bewaart altijd bekijken en aanpassen.

• Kwaliteitscontrole: meerdere instanties controleren de gegevens, wat de kwaliteit verbetert.

• Juridische correctheid: de data-uitwisseling verloopt op een juridisch correcte manier

Heb je (nog) geen systemen (bv. CRM-toepassing) om verenigingsdata te beheren? Doe dan toch alvast de volgende voorbereiding:

• Verzamel en uniformiseer de verenigingsdata die nu vaak verspreid zitten over verschillende diensten en softwarepakketten
• Gebruik hiervoor een Excel-bestand op basis van het datamodel van het Verenigingsregister(opent in nieuw venster).
• Info en achtergrond bij de migratie-excel(opent in nieuw venster) van het Verenigingsregister

Drie basisopties om aan te sluiten:

1. Publieke verenigingsgegevens raadplegen via Publieke API

   • Wat? Toegang tot en hergebruik van algemene verenigingsgegevens zoals naam, beschrijving, adres en contactinfo.
   • Hoe? Door een koppeling met de publieke API voor geautomatiseerd raadplegen en hergebruiken op je website en andere applicaties.
   • Voor wie? Iedereen, zonder inloggen via het Verenigingsloket en eventueel je eigen applicaties
   • Mogelijke toepassingen? Digitale verengingsgids op je website, overzicht verenigingen volgens thema

2. Niet-publieke verenigingsgegevens raadplegen via MAGDA-aansluiting:

   • Wat? Toegang tot beschermde gegevens zoals contactinfo van vertegenwoordigers en bankrekeningnummers.
   • Hoe? Dien een aansluitingsdossier in bij MAGDA en gebruik de niet-publieke API.
   • Voor wie? Lokale overheden en Vlaamse entiteiten voor dienstverlening aan verenigingen
   • Mogelijke toepassingen? Automatisch invullen aanvraagformulieren, opzoeken niet-publieke gegevens vanuit lokale ICT-systemen of CRM, ...
   • Belangrijk: Stuur correcties ook door naar het Verenigingsregister.

3. Niet-publieke verenigingsgegevens beheren via MAGDA-aansluiting:

   • Wat? Beheer en actualiseer verenigingsgegevens (ook van vertegenwoordigers) door alle overheden die ervan gebruik maken (decentraal beheer)
   • Hoe? Verzamel wijzigingen en stuur deze via MAGDA’s niet-publieke API
   • Waarom? Voorkom veroudering van gegevens en bevorder gezamenlijk beheer
   • Mogelijke toepassingen? Hergebruik gegevens in CRM, mid-office of back-end toepassingen, lokaal e-loket, ...

Meer info via de documentatie van het Verenigingsregister(opent in nieuw venster)

Digitale dienstverlening is essentieel voor een efficiënte overheid. Het biedt verenigingen directe toegang tot actuele informatie over diensten en ondersteuning, en stelt medewerkers in staat snel en accuraat op vragen te reageren.

Wat is de Lokale Producten- en Dienstencatalogus (LPDC)

Een centraal beheersysteem met beschrijvingen van lokale producten en diensten. Het is een lokale variant van sjablonen uit de Interbestuurlijke Producten- en Dienstencatalogus (IPDC). Als bestuur kan je eenvoudig een sjabloon uit IPDC hergebruiken en aanpassen volgens de lokale voorwaarden, contactgegevens, ...

Voordelen van centraal beheer van dienstverleningsinformatie via LPDC:

• Eén centrale locatie: verenigingen vinden alle relevante overheidsdiensten op één plek, zonder websites van verschillende overheden te moeten doorzoeken.
• Toegankelijk voor alle overheden: deze centrale databank maakt informatie toegankelijk voor alle overheidsniveaus
• Altijd actueel: de beschrijvingen van de dienstverlening blijven up-to-date omdat deze uit één bron komt.

Gebruik je al de Lokale Producten- en Dienstencatalogus (LPDC) via het Loket Lokale Besturen? Dan kan je een heel aantal sjablonen van de productcatalogus(opent in nieuw venster) aanpassen voor je eigen lokaal bestuur.

• Volg deze stappen:

1. Ga naar de LPDC-module via Loket Lokale Besturen

2. Kies het sjabloon (concept) van het product dat je wil publiceren

3. Pas de voorwaarden en andere velden aan zodat ze overeenkomen met je lokaal reglement

4. Voeg de website toe waar de vereniging de aanvraag digitaal kan starten (bij ‘procedure’)

5. Duid de doelgroep ‘vereniging’ aan

6. Verzend dit product naar de Vlaamse Overheid

• Eén uur later zal dit product terug te vinden zijn op het Verenigingsloket

Is er een lokaal beheersysteem voor digitale diensten?

• Nee:
  • Beheer je dienstverleningsinformatie rechtstreeks via de LPDC-module(opent in nieuw venster) in het Loket voor Lokale Besturen.
  • Hergebruikt deze info in je dienstverleningsprocessen of op je website, via de API van IPDC.
• Ja:
  • Bepaal waar je de dienstverleningsinformatie beheert (als masterdata):
    • Optie 1 via het lokale systeem: stuur alle wijzigingen door naar de LPDC-module als gelinkte open data.
    • Optie 2 direct beheer in de LPDC-module (van het Loket Lokale Besturen): zorg voor een omgekeerde integratie met het lokale systeem.

Hoe de informatie hergebruiken?

• Optie 1 via het lokale systeem: de informatie wordt automatisch opgehaald voor gebruik in andere systemen.
• Optie 2 via de API van IPDC (dus niet van LPDC)

Aandachtspunten: Belangrijke velden moeten ingevuld zijn zodat je producten ook op het Verenigingsloket worden getoond:

• Doelgroep: selecteer ‘Vereniging’
• Procedure-link naar aanvraag: een link naar je lokale website waar de aanvraag van het product kan worden opgestart
• Status: ‘gepubliceerd’ zonder foutmeldingen
• Publicatiekanaal: ‘IPDC v3’ is aangevinkt

Digitale dienstverlening is ook voor Vlaamse entiteiten essentieel voor een efficiënte werking. Het biedt verenigingen directe toegang tot actuele informatie over diensten en ondersteuning, en stelt medewerkers in staat snel en accuraat op vragen te reageren.

Wat is de Interbestuurlijke Producten- en Dienstencatalogus (IPDC)

Een centraal beheersysteem met beschrijvingen van producten en diensten die alle overheden (dus ook federaal, provinciaal en lokaal) aanbieden op het Vlaamse grondgebied. Als entiteit kan je eenvoudig een sjabloon uit IPDC hergebruiken en aanpassen volgens de eigen voorwaarden, contactgegevens, …

Voordelen van centraal beheer van dienstverleningsinformatie via IPDC:

• Eén centrale locatie: verenigingen vinden alle relevante overheidsdiensten op één plek, zonder websites van verschillende overheden te moeten doorzoeken.
• Toegankelijk voor alle overheden: deze centrale databank maakt informatie toegankelijk voor alle overheidsniveaus
• Altijd actueel: de beschrijvingen van de dienstverlening blijven up-to-date omdat deze uit één bron komt.

Gebruik je al de redactieomgeving van het Vlaamse webplatform om je dienstverlening digitaal te beheren? Kijk dan na welke dienstverleningsproducten ook voor de doelgroep ‘vereniging’ van toepassing zijn. Vaak is een dienst of product immers voor meerdere doelgroepen relevant.

• Volg hiervoor deze stappen:

1. Ga naar de redactieomgeving
2. Zoek het product dat je wil aanpassen
3. Duid de doelgroep ‘vereniging’ aan
4. Zorg ervoor dat ook de velden ‘link naar de aanvraag’ en ‘uitvoerende organisatie’ zijn ingevuld voor het product
5. Sla de wijzigingen op

• Eén uur later is dit product terug te vinden op Verenigingsloket

Invoeren en updaten van productinformatie:

• Enige methode: gebruik de redactieomgeving van het Vlaamse Webplatform om dienstverleningsinformatie in te voeren en bij te werken in IPDC

Belangrijk aandachtspunt:

• Tijdelijke dubbele inspanning: als je informatie lokaal beheert, is automatische doorstroming naar IPDC nog niet mogelijk. Voorlopig moet je de informatie op beide plaatsen onderhouden.

Hergebruik van Informatie:

• Via API: Haal de beheerde informatie op via de API van IPDC voor gebruik in dienstverleningsprocessen of op je eigen website

Rechten en opleiding:

• Toegang: medewerkers moeten gebruiksrechten hebben om in de redactieomgeving te werken.
• Opleiding: nieuwe redacteurs krijgen training van Digitaal Vlaanderen om hen te ondersteunen.

Op deze wijze kunnen vertegenwoordigers van verenigingen zich aanmelden op alle overheidswebsites en je eigen applicaties via hetzelfde beveiligde systeem.

Er zijn twee methoden:

1. Eenvoudige navigatiebalk (global header met basis toegangsbeheer):
   - Een vaste navigatiebalk bovenaan overheidswebsites.
   - Een veilige manier om in te loggen op je site en van daaruit te navigeren naar algemene overheidssites zoals Mijn Burgerprofiel of het Verenigingsloket.
   - Inloggen namens een vereniging is op deze manier nog niet mogelijk.
   
2. Uitgebreide navigatiebalk (global header met gekoppeld toegangsbeheer of single sign-on):
   - Een vaste navigatiebalk bovenaan overheidswebsites.
   - Een veilige manier om in te loggen op je site en toegang te krijgen tot andere beveiligde functionaliteiten (zoals je lokale evenementenloket, reserveringssysteem, etc.).
   - Hiermee kan een vertegenwoordiger van de vereniging navigeren naar andere overheidssites zonder opnieuw in te loggen.

Voor de implementatie van de tweede optie is het noodzakelijk om gebruik te maken van de bouwsteen ‘toegangsbeheer’ (ACM). ACM garandeert de identiteit van gebruikers bij het inloggen op online diensten via betrouwbare bronnen zoals het Rijksregister, KBO of Verenigingsregister. Speciaal voor het Verenigingsloket en ondersteunende overheidswebsites maakt ACM inloggen namens verenigingen mogelijk. Daarom wordt dit geavanceerde toegangsbeheer sterk aanbevolen.

Stappen die je kan zetten als er geen uitgebreide navigatiebalk met ACM-koppeling is:

• Maak een lijst van de verschillende toepassingen/platformen/applicaties waartoe verenigingen toegang moeten hebben

• Controleer per toepassing welke aanmeldprocedure momenteel wordt gebruikt

• Beoordeel de toegevoegde waarde en impact van het toestaan van aanmelden als vereniging voor elke toepassing.

Nieuwe aansluiting

1. Global header met eenvoudig toegangsbeheer
   • Opgelet: hierdoor kan een vertegenwoordiger van een vereniging zich nog niet aanmelden namens een vereniging op je website of applicatie. Daarom is een aansluiting met gekoppeld toegangsbeheer altijd aangeraden.
   • Waar vraag je wat aan?
     • Vul het online formulier(opent in nieuw venster) in.
     • Je ontvangt per e-mail instructies over het toevoegen van de Global header en footer aan je website.
     • De websitebeheerder gaat aan de slag met deze instructies.
   • Doorlooptijd: de installatie-instructies voor de Global header worden enkele dagen na aanvraag verstuurd
2. Aansluiting van de Global header met gekoppeld toegangsbeheer
   • Via deze aansluiting kunnen vertegenwoordigers van een vereniging zich wel op je website of applicatie aanmelden namens een vereniging en gebruikmaken van je digitale dienstverlening. Ze kunnen ook zonder opnieuw aan te melden gebruikmaken van diensten op andere overheidswebsites die dezelfde aansluiting hebben (‘single sign-on’). Daarom is deze aansluiting sterk aanbevolen.
   • Waar vraag je wat aan?
     • Vul een online formulier(opent in nieuw venster) voor eenvoudig toegangsbeheer aan (zie stap 1)
     • Vul een online formulier(opent in nieuw venster) voor koppeling met ACM aan
     • Het aansluitingsteam van Digitaal Vlaanderen neemt contact op
     • De websitebeheerder voert de technische wijzigingen uit

Wijziging bestaande aansluiting

1. Aanpassing Global Header: van ‘eenvoudig’ naar ‘gekoppeld’ Toegangsbeheer
   • Stuur een e-mail naar aansluitingen.verenigingsloket@digitaal.vlaanderen.be
2. Uitbreiding Global Header: toevoegen doelgroep ‘Verenigingen’
   Heb je al een ACM-integratie maar kunnen gebruikers nog niet inloggen namens een vereniging?
   • E-mail naar integraties@vlaanderen.be om je aansluiting uit te breiden
   • Wijzig je ACM/IDM-integratiedossier bij het onderdeel ‘2.5 Uitgeleverde attributen’

1. Terminologie
   • ​​​​Doelgroep verwijst naar de bron die ACM bevraagt
     • EA = KBO (= bijvoorbeeld vzw’s)
     • VER = Verenigingsregister (= feitelijke verenigingen)
   • Duid zowel EA als VER aan om de doelgroep verenigingen volledig te ontsluiten
2. Callback url’s
   • Geef per omgeving aan welke URL naar welke doelgroep verwijst
3. Autorisatie attributen

   • Dit specificeert welke gebruiker of hoedanigheid zich mag aanmelden als een bepaalde doelgroep binnen de applicatie.

   • 3 mogelijke hoedanigheden :

     • Hoofdvertegenwoordiger FV

     • Wettelijke vertegenwoordigers KBO-verenigingen

     • Vertegenwoordiger met IDM-rechten

4. Uitgeleverde attributen (ACM claims)

   • Bundel claims en ontvang ze als één geheel.

     • Vraag dit aan via het aansluitingsformulier.

     • Voer de technische implementatie uit met de code.

   • Vraag voor de doelgroep verenigingen de volgende attributen aan:

     • Rijksregisternummer

     • Voornaam

     • Familienaam

     • Organisatiecode (= Verenigingscode)

     • Organisatienaam (= Verenigingsnaam)

5. Overzicht gebruiksrechten
   • ​​​​Breidt eventueel de rechten van de eigen applicatie uit voor verenigingen
   • Neem de rechten voor dossiers op die je meestuurt naar DOSIS
6. Vereniging als brede doelgroep
   • De vo_vcode claim identificeert of de aangemelde entiteit een vereniging of een economische actor is. Rechtsvormen zoals vzw’s en stichtingen worden gecategoriseerd als ‘vereniging’. De complete lijst van rechtsvormen is beschikbaar onder KBO Rechtsvormen.
   • De claim vo_is_ver_hoofd_vertegenwoordiger duidt aan dat de betreffende persoon de hoofdvertegenwoordiger van de vereniging is. Als hoofdvertegenwoordiger heeft men als ‘administrator’ toegang tot alle informatie, inclusief de status van dossiers. In de toekomst zal uit het Verenigingsregister blijken of iemand de hoofdvertegenwoordiger is. Voorlopig wordt iedereen die in het Verenigingsregister staat als zodanig erkend, waarbij de logica enkel nagaat of de persoon al dan niet in het register voorkomt.
   • De vo_doelgroepcode is een claim binnen een security token die aangeeft welke bron geraadpleegd is voor de identiteit waarmee iemand zich aanmeldt. Het wordt onder meer gebruikt in DOSIS om het type ID in de claim vo_orgcode te bepalen.
     • In deze context verwijst de doelgroepcode naar de bron, niet naar de functionele structuur van de organisatie. Zo heeft een vzw de doelgroepcode EA, omdat de authentieke bron voor vzw’s het KBO is, wat verwarring kan veroorzaken.
     • Deze code in een security token geeft dus aan welke bron is geraadpleegd voor de identiteit waarmee men zich aanmeldt en is belangrijk voor het identificeren van het type ID in de claim vo_orgcode in DOSIS.

Single Sign-On, Direct Linking en de rol van ACM

• Een lid van een verenigingslid registreert zich op het Verenigingsloket steeds in naam van de betreffende vereniging. Dit houdt in dat de persoon als gebruiker wordt geïdentificeerd en bekend is bij welke vereniging hij of zij hoort. De authenticatie vindt plaats via de Vlaamse digitale bouwsteen ACM.
• Idealiter zou de gebruiker ingelogd blijven namens de vereniging wanneer hij via het Verenigingsloket doorklikt naar een andere applicatie, zoals een lokaal e-loket. Dit is het Single Sign-On proces: de gebruiker logt eenmalig in en kan vervolgens zonder opnieuw te moeten inloggen naar andere applicaties navigeren, wat de gebruiksvriendelijkheid aanzienlijk verbetert.
• Het kan ook aangewezen zijn om een gebruiker meteen door te verwijzen naar een specifieke pagina binnen een applicatie in plaats van de standaard homepagina. Dit is Direct Linking. Het Verenigingsloket gebruikt dit principe om gebruikers die een product aanvragen direct naar de juiste applicatie en de desbetreffende pagina te leiden waar zij hun aanvraag kunnen doen. Hierdoor wordt voorkomen dat gebruikers na het starten van een aanvraag op een applicatie belanden waar ze opnieuw moeten zoeken naar het product om hun aanvraag af te ronden.

Het opzetten van een SSO en Direct Linking gaat vaak samen om een optimale gebruikerservaring te bereiken en is afhankelijk van de eigen specifieke situatie.

Single Sign-On met eigen applicatie

• Het Verenigingsloket voegt bij elke link (URL) een extra queryparameter ‘login_hint’ toe. Dit dient om aan te geven voor welke vereniging de gebruiker is aangemeld op het Verenigingsloket. Deze extra parameter kan vervolgens in de eigen applicatie gebruikt worden om het authenticatieverzoek naar ACM te structureren. ACM zal deze ‘login_hint’-parameter herkennen en de gebruiker direct aanmelden voor de betreffende vereniging.
  
• Proces:
  • Voor elke link die leidt naar een applicatie van een gegevensinitiator, voegt het Verenigingsloket een extra parameter toe, genaamd login_hint. Deze parameter, in een gestandaardiseerd ACM-formaat en Base64-gecodeerd, bevat een waarde die specificeert voor welke vereniging de gebruiker momenteel aangemeld is in het loket.
  • Wanneer een gebruiker op de link klikt, wordt hij/zij doorgestuurd naar de applicatie. Het is aan de applicatie om te verifiëren of de gebruiker reeds ingelogd is. Indien dit niet het geval is bij het eerste gebruik, moet de applicatie een authenticatieverzoek naar ACM versturen.
  • Bij het opbouwen van de URL voor deze aanvraag moet de applicatie de login_hint zoals doorgegeven vanuit het Verenigingsloket, volledig overnemen. De naam van de parameter (login_hint) en de base64-gecodeerde string moeten behouden blijven.
  • ACM zal de string interpreteren en de gebruiker opnieuw aanmelden als de aangegeven vereniging voor de betreffende applicatie.
  • De gebruiker is correct geïdentificeerd binnen de bevoegdheden en toepassingen van jouw organisatie.
    
    Belangrijke opmerking:
  • Als de login_hint parameter niet correct of helemaal niet wordt meegegeven, zal de gebruiker bij ACM in stap 4 een aanmeldscherm zien waarbij hij opnieuw een hoedanigheid moet kiezen. De kans bestaat dan dat de gebruiker een andere vereniging of foutieve hoedanigheid selecteert en de aanvraag dus niet correct gebeurt.
  • Gebruikers kunnen toegang krijgen tot de applicatie zonder dat ze zijn ingelogd in het Verenigingsloket. In zo’n situatie zal de login_hint parameter ontbreken.

• Technische info in verband met gericht aanmelden

  • Valideer als applicatie zelf eerst de login_hint:

    • cap_hint: BUR

    • cap_hint: EA + code_hint: <ondernemingsnummer>

    • cap_hint: VER + code_hint: <vcode>

    • voor GID & andere doelgroepen telkens ook een code_hint verplicht
      De gouden regel is: geef voor BUR geen code_hint mee, voor alle andere doelgroepen wel.

  • ACM biedt geen ondersteuning voor gerichte aanmeldingen waarbij alleen specifieke doelgroepen zichtbaar zijn, zoals uitsluitend feitelijke verenigingen of ondernemingen.

  • Als een applicatie toch een ‘verkeerde’ login_hint meestuurt tijdens de authenticatie, beland je op het ACM-aanmeldscherm waar je uit al je entiteiten kunt kiezen (niet specifiek gericht), wat resulteert in een loop als je een van de identiteiten selecteert.

Direct Linking tussen het Verenigingsloket en jouw applicatie

• De gebruiker wordt vanuit het Verenigingsloket doorverwezen naar een aanvraagpagina voor een specifiek product dat hij/zij heeft aangeklikt in het Verenigingsloket.
• Er zijn verschillende manieren om dit te organiseren afhankelijk van de applicatie, maar kan bijvoorbeeld via:
  • een specifieke URL: https://jouwtoepassing.be/product/3102. In dit voorbeeld verwijst men met een unieke URL naar een product met ID 3102.
  • een query parameter in de URL: https://jouwtoepassing.be/jouwpagina?producttype=3102. In dit voorbeeld verwijst men met de parameter producttype in een algemene URL naar een product met ID 3102.
  • nog andere opties, maar de vermelde URL in de productfiche van het betreffende IPDC/LPDC-product is bepalend. Het Verenigingsloket zal de Procedure-URL(‘s) uit de productfiche direct overnemen.
• Als authenticatie niet vereist is, volstaat het meestal om de juiste URL door te geven. Na het aanklikken kan de applicatie de URL waarschijnlijk interpreteren en doorverwijzen naar de betreffende pagina. Dit is afhankelijk van de architecturale werking van de applicatie.
• Het wordt complexer als er wel authenticatie nodig is. Er moet een authenticatieproces bij ACM plaatsvinden voordat je naar de juiste pagina kan navigeren. Maar zonder extra maatregelen verliest men door de ACM-authenticatiestap de context van de specifieke pagina waarnaar verwezen wordt. ACM herkent de specifieke pagina’s niet en stuurt na authenticatie altijd terug naar de basis-URL van de applicatie, zoals geregistreerd bij ACM in het integratiedossier. Dit is vaak de startpagina van de applicatie, wat niet ideaal is voor de gebruikerservaring. Om dit te omzeilen, kan men een extra ‘state’ parameter invoeren.
  
• Proces:
  • De applicatie-implementator voorziet voor elk product een URL die het mogelijk maakt een specifiek product te identificeren. Dit kan via een specifieke URL, query parameter, enzovoort. In het bovenstaande voorbeeld wordt een query parameter gebruikt. Deze URL moet worden opgenomen in de productfiche van het IPDC-product.
  • Wanneer een gebruiker op de link klikt, wordt hij/zij doorgestuurd naar de applicatie. Het is aan de applicatie om te verifiëren of de gebruiker al dan niet is ingelogd. Indien dit niet het geval is bij het eerste bezoek, moet de applicatie een authenticatieverzoek naar ACM sturen.
  • Om te voorkomen dat na authenticatie de context van de specifieke productpagina die we wilden benaderen verloren gaat, kan een state parameter worden toegevoegd aan de URL-structuur voor ACM. In deze state parameter kan bijvoorbeeld worden bijhouden om welk product het gaat, zoals in bovenvermeld voorbeeld de waarde 3102 die naar het product verwijst.
  • Na registratie garandeert ACM dat de state parameter AS-IS wordt teruggestuurd, zonder enige wijziging of interpretatie, samen met de redirect.
  • De gebruiker heeft zich aangemeld in de applicatie van de gegevensinitiator. Door de state parameter uit te lezen en te interpreteren, kan de applicatie automatisch de pagina oproepen die oorspronkelijk was bedoeld.
    
    Belangrijke opmerking
  • De state parameter kan breder worden toegepast dan de “eenvoudige” implementatie die hierboven is beschreven. De inhoud en het formaat van de state parameter kunnen volledig door de gegevensinitiator worden bepaald. Door gebruik te maken van een gestructureerd formaat (zoals URI, JSON, etc.), is het mogelijk om extra parameters toe te voegen voor verschillende doeleinden. Hoe dan ook, ACM zorgt ervoor dat het de parameter ontvangt en ongewijzigd terugstuurt na authenticatie.
• Documentatie ACM:
  • algemene documentatie en aansluiting bij ACM: Gebruikers en rechten tot je digitale toepassingen beheren | Vlaanderen.be
  • technische documentatie ACM: Toegangsbeheer (ACM) - Gebruikersomgeving Applicatie- en platformdiensten - Confluence (atlassian.net)(opent in nieuw venster)
    

Gevolgen van Single Sign-On

• Er kunnen op het Verenigingsloket verschillende hoedanigheden aanmelden: burgers, verenigingen en economische actoren. Voor elke hoedanigheid wordt de login hint meegestuurd.
• Als een gebruiker zich bij het Verenigingsloket aanmeldt in een andere hoedanigheid dan vertegenwoordiger van een vereniging, wordt dit via toastmessages duidelijk gemaakt maken aan de gebruiker en worden ze indien nodig doorverwezen naar bijvoorbeeld het eloketondernemers.be. Toch blijft het mogelijk dat een gebruiker in een andere hoedanigheid dan verenigingsvertegenwoordiger dienstverlening aanvraagt op het Verenigingsloket en zich via de SSO-integratie in die hoedanigheid aanbiedt op een applicatie. Hou hiermee rekening als een burger of economische actor niet dezelfde acties mag uitvoeren als een vertegenwoordiger van een vereniging.
• Vanuit het Verenigingsloket kan er geen aparte SSO-ervaring per aangesloten applicatie worden opgezet. Het Verenigingsloket haalt de productinformatie en bijhorende aanvraaglinks op vanuit de IPDC-bouwsteen, en geeft deze weer zonder hier iets aan te wijzigen.
• Enkele concrete voorbeelden:
  • Een burger meldt zich aan op het Verenigingsloket en start een aanvraag voor een evenement bij de eigen gemeente
    • Zowel burgers als verenigingen kunnen evenementen aanvragen. Het is aan de applicatie van de gemeente die deze aanvragen verwerkt, om desgewenst te controleren of de aanvraag wel degelijk onder de juiste hoedanigheid wordt opgestart, bv. om te vermijden dat een dossier aan een burger gekoppeld wordt, terwijl het dossier eigenlijk een vereniging betreft.
  • Een gebruiker komt aangemeld als vertegenwoordiger van een vennootschap naar het Verenigingsregister, en klikt daar door naar het aanvraagformulier van een dienstverleningsproduct aangeboden door een departement van de Vlaamse Overheid, dat exclusief bestemd is voor verenigingen.

    • Dan is het aan de applicatie van het departement die de afhandeling begeleidt, om een check uit te voeren op de hoedanigheid van de aangemelde gebruiker. Indien deze hoedanigheid niet toegestaan is, dan zal de applicatie de gebruiker hierover idealiter informeren en eventueel alternatieve acties aanbieden (zoals: wisselen van account). Gebeurt dit niet, dan kan er een dossier worden opgestart dat bij de behandeling door een dossierbehandelaar als niet-ontvankelijk zal worden afgewezen. Deze extra verwerkingsinspanning wordt idealiter vermeden.​​​​​​​

• Overwegingen om de impact van SSO en direct linking op de eigen toepassing in te schatten:

  • Zijn de beschikbare aanvraagprocedures exclusief bedoeld voor verenigingen, of ook voor andere doelgroepen?

  • Is er een verschil in aanvraagprocedure tussen de doelgroepen?

  • Zijn er bepaalde mechanismes ingebouwd in de toepassing die controleren op de hoedanigheid waarmee een gebruiker is aangemeld?

  • Zijn er mechanismes ingebouwd in de toepassing die gebruikers informeren over een mogelijke ‘verkeerde’ hoedanigheid, en die alternatieve acties kunnen we aanbieden?

DOSIS(opent in nieuw venster), wat staat voor Dossier Status Informatie Systeem, verzamelt en ontsluit informatie over de aanwezigheid en status van dossiers bij Vlaamse of lokale overheidsdiensten. Hoe meer toepassingen hun dossierstatussen naar DOSIS sturen, hoe beter verenigingen, burgers en bedrijven een helder overzicht krijgen van hun dossiers bij verschillende instanties.

Stappen die je kan zetten als nog geen digitale afhandeling van dossiers is:

• Maak een lijst van de verschillende diensten die nu al digitaal aangeboden worden aan verenigingen en duid aan welke dossiers digitaal kunnen opgevolgd worden
  • welke statussen gebruiken jullie nu? zijn deze duidelijk voor verenigingen?
  • wanneer is een dossier “afgerond”? Heeft elk proces een einde?

Dossiers voor verenigingen gebaseerd op vCode
Een dossier vloeit voort uit het aanvragen van een bepaalde dienst of product in naam van een vereniging. Elke vereniging heeft een unieke vCode. Nu ondersteunt de API ook de ID’s van verenigingen (de vCode). Dit is de unieke identificatiecode waarmee de vereniging bekend is in het Verenigingsregister, beginnend met de letter ‘V’ gevolgd door 7 cijfers (bijvoorbeeld V0001120).

Product gekoppeld aan een dossier
Elk dossier (en dus elke dossierstatus) is gekoppeld aan een bepaald IPDC- of LPDC-product dat is aangevraagd. Deze koppeling gebeurt via een API via dewelke de unieke ID van het betreffende IPDC- of LPDC-product wordt uitgewisseld.

Hoe sluit je aan bij DOSIS?

• Vul je het online formulier(opent in nieuw venster) in
• Daarna neemt het integratieteam van DOSIS contact op