Skip to end of metadata
Go to start of metadata

gekoppledThe user stories we base the SCZ infrastructure on, are in Dutch.

Om een extra idee te krijgen van wat SCZ vooralsnog wil bieden, delen we hier de 'user stories' (in hoofdlijnen) waarvoor we met SCZ een oplossing willen bieden.

Uitgangspunten

De samenwerkingsorganisatie (CO, Collaborative Organisation) wil:

    • onderzoeksdiensten op een laagdrempelige manier delen en veilige toegang creëren voor gebruikers van diverse organisaties in binnen- en buitenland
    • het toegangsmanagement tot COs en diensten schaalbaar en transparant kunnen regelen
    • in potentie elk type gebruiker kunnen uitnodigen voor deelname in de samenwerking
    • web- en non-webgebaseerde omgevingen met een instellingsaccount toegankelijk maken
    • de toekenning van lidmaatschappen kunnen delegeren
    • identiteiten en attributen uit verschillende bronnen makkelijk kunnen samenvoegen
    • de voor de CO relevante diensten als bundel met WAYF naar IdPs presenteren (proxy, ook eduGAIN)

User stories voor:

Managers van samenwerkingsorganisaties

    1. Als CO admin wil ik nieuwe gebruikers kunnen uitnodigen/inschrijven voor deelname in de CO zodat ik eenvoudig mijn groep kan beheren.

    2. Als CO admin wil ik (sub)groepslidmaatschap kunnen administreren zodat ik kan bepalen wie op basis daarvan wat kan doen binnen mijn groep (CO).

    3. Als CO admin wil ik policies kunnen definiëren voor herbevestiging van deelname en rechten van gebruikers, zodat periodiek wordt bevestigd dat leden van mijn CO nog toegang moeten houden tot de resources.

    4. Als CO admin wil ik policies kunnen definiëren voor deprovisioning van gebruikers, zodat gebruikersaccounts conform de policy zoveel mogelijk worden opgeruimd

    5. Als CO admin wil ik de audit trails kunnen inzien en reviewen (time stamp nieuwe gebruikers, uitdelen/intrekken rechten) zodat ik kan (laten) zien wie wie wanneer toegang heeft verleend of ontnomen tot een CO.

    6. Als CO admin wil ik dat geregistreerde gebruikers en hun lidmaatschappen beschikbaar komen voor service providers (SP's), zodat SP's op basis daarvan in hun systemen/resources accounts kunnen aanmaken en eventueel autorisatie-beslissingen kunnen nemen.

    7. Als CO admin wil ik kunnen bepalen welke CO members nieuwe leden kunnen uitnodigen voor een CO, zodat ik het uitnodigen zoveel mogelijk kan delegeren/decentraliseren. (aandrager user-story: Ton Smeele)

    8. Als CO admin wil ik de toegang tot bepaalde diensten beperken tot authenticaties en/of identiteiten met een bepaalde LoA (Level of Assurance), zodat ik bepaalde diensten/gegevensbronnen extra kan afschermen en de juiste mate van zekerheid heb dat alleen de juiste personen toegang hebben tot diensten
    9. Als CO admin wil ik inzicht in het LoA (Level of Assurance) van identiteiten, zodat ik bij het maken van groepen waar later rechten (bijv. schrijf of admin rechten) aan worden ontleend, kan bepalen of de identiteit van de gebruiker voldoende LoA heeft.
    10. Als CO admin wil ik dat een uitgenodigde gebruiker indien mogelijk een instellingsaccount of ander account met een van te voren gespecificeerde minimale LoA gebruikt.
    11. Als CO admin wil ik dat eindgebruikers additionele informatie kunnen registreren en beheren (self-asserted attributen zoals: mail adres, telefoonnr, titel) zodat de systemen waar ze bij moeten kunnen worden voorzien van de benodigde informatie als die gegevens niet worden aangeleverd door (1 van de) IdPs' of attribute providers van de gebruiker.
    12. Als CO admin wil ik van identiteiten weten bij welke instelling(en) ze (nog) werkzaam zijn zodat ik kan bepalen of ik ze nog toegang moet geven (ook irt non-web resources) (indien actuele aanstellingsinfo niet beschikbaar is, is 'lastseen-on-SURFconext' een 2nd best) en ik gebruikers niet onnodig hoef te vragen zich opnieuw bij hun instelling te authenticeren.
    13. Als CO admin wil ik een AUP kunnen tonen en de gebruiker kunnen dwingen deze te accepteren, zodat de gebruiker altijd op de hoogte is van de geldende regels binnen de CO
      1. Als beheerder wil ik een audittrail hebben met welke AUP wanneer door welke identiteit is geaccepteerd, zodat ik een legal basis heb voor acties bij b.v. misbruik van resources door een identiteit.
      2. Als mijn AUP wijzigt wil ik dat de gebruiker die opnieuw dient te accorderen zodat ik kan aantonen dat ook de nieuwe AUP bij de gebruiker bekend mag worden verondersteld.

Eindgebruiker

    1. Als eindgebruiker wil ik mij eenvoudig kunnen inschrijven voor een CO (Collaborative Organisation) zodat ik via die CO toegang kan krijgen tot systemen/resources die ik nodig heb voor mijn werk/studie/onderzoek.
    2. Als eindgebruiker wil ik zien welke gegevens een CO nodig heeft zodat ik weet welke gegevens ik moet aanleveren om met de dienst te kunnen werken.
    3. Als eindgebruiker wil ik additionele informatie kunnen beheren (self asserted attributen zoal: mail adres, telefoonnr, titel) zodat de systemen waar ze bij moeten kunnen, worden voorzien van de benodigde informatie als die gegevens niet worden aangeleverd door de IdP of (1 van de) attribute providers van de gebruiker of wanneer aangeleverde informatie onjuistheden bevat.
    4. Als eindgebruiker wil ik eenvoudig toegang tot gedeelde bronnen zodat ik snel, makkelijk en met de juiste veiligheid en met de authenticatie-middelen die de service provider beschikbaar stelt (in ieder geval te ondersteunen: instellingsaccount, social ID) bij de systemen kan die ik nodig heb voor mijn werk/studie/onderzoek:
      1. Als eindgebruiker wil ik ook makkelijk en veilig bij non-webdiensten kunnen inloggen en kunnen werken met de authenticatie-middelen die de service provider beschikbaar stelt, zodat ik mijn werk/studie/onderzoek kan doen:

        1. Als eindgebruiker wil ik one time passwords kunnen genereren en registreren;

        2. Als eindgebruiker wil ik applicatie specifieke wachtwoorden kunnen genereren en registreren;

        3. Als eindgebruiker wil ik ssh keys kunnen registreren;

        4. Als eindgebruiker wil ik X509 certificaten kunnen aanvragen en registreren.
    5. Als eindgebruiker wil ik snappen met welk middel ik me moet authenticeren en/of eerder heb geauthenticeerd, zodat ik me niet per abuis met een andere identiteit aanmeld.
    6. Als eindgebruiker wil ik bij elke nieuwe CO waar ik aan wordt toegevoegd eenvoudig de eerder door mij aan SCZ geleverde informatie over kunnen nemen in de nieuwe CO.
    7. Als eindgebruiker wil ik mijn SCZ-account niet verliezen als ik overschakel/moet overschakelen van identiteit (b.v. als ik wissel van instelling), zodat ik niet alles opnieuw hoef aan te maken in COmanage, en met mijn andere account(s) nog bij de resources kan waar ik rechten toe heb op basis van dat/die account(s) (account kunnen koppelen aan meerdere identiteiten - account linking).
    8. Als eindgebruiker wil ik mijn deelname in de CO kunnen opheffen zodat ik zelf in control ben van mijn identiteit en de relatie met een CO, terwijl ik toch eenvoudig in andere CO's kan deelnemen zonder alles opnieuw aan te hoeven maken in COmanage (opmerking: bij het wissen van gegevens spelen velen belangen, niet alleen de wens van de gebruiker, maar b.v. ook mogelijkheden in databases, onderzoeksbelangen, belangen bij service providers etc. Voor de gebruiker dient duidelijk te worden wat gevolgen zijn van het bij SCZ ontkoppelen van zijn identiteit van een CO).

    9. Als eindgebruiker wil ik een aanvraag kunnen indienen om mijn rol aan te laten passen (aandrager user-story: Remco Rohde, RUG).

    10. Als eindgebruiker wil ik begrijpen waar mijn gegevens wel en waar niet verdwijnen indien ik bij/in SCZ vraag om gegevens te wissen.

IT-afdeling van de instelling

In de rol van dienstaanbieder

    1. Als dienstaanbieder wil ik mijn dienst koppelen aan een CO zodat mensen die er bij moeten kunnen, dat via COmanage/SCZ kunnen en ik dan de juiste attributen ontvang om b.v. accounts te provisionen

    2. Als dienstaanbieder wil ik op (al dan niet geautomatiseerde, denk aan API's etc) eenvoudige wijze authenticatie- (AuthN) en autorisatie- (AuthZ) informatie kunnen consumeren en mappen op de interne gebruikers- en gebruiks-administratie van de dienst, zodat ik met minimale moeite accountbeheer kan doen:

      1. als dienstaanbieder wil ik geautomatiseerd (b.v. via een API) toegang hebben tot uitlezen van de leden van een CO-groep zodat resources binnen mijn dienst kunnen worden geautoriseerd(aandrager user story: Gabor Nyers).
      2. als dienstaanbieder wil ik geautomatiseerd (b.v. via een API) toegang tot een lijst van de CO's waar de gebruiker lid van is zodat bij provisioning van een nieuwe resource de gebruiker uit deze lijst de CO kan kiezen welke toegang tot de resource heeft (aandrager user story: Gabor Nyers).
    3. Als dienstaanbieder wil ik geautomatiseerd (API?) een provisioning van een nieuw lid voor een CO kunnen triggeren, zodat gebruikers vanuit mijn dienst soepel voor een CO uitgenodigd kunnen worden.
    4. Als beheerder wil ik op elk moment kunnen zien wie manager(s) van een CO is (zijn), zodat ik, bijvoorbeeld in het geval van bij zich misdragende gebruikers, contact op kan nemen met een manager bijvoorbeeld om af te spreken wie welke actie neemt.
    5. Als beheerder wil ik tooling hebben om te kunnen controleren dat mijn koppeling goed werkt is, zodat ik niet/minder afhankelijk ben van en niet hoef te wachten op beheerders van een centrale COmanage/SCZ-dienst (denk aan test-IdP, test CO, SLA-monitoring, end-to-end-test, aansluitomgeving, aansluitdocumentatie).
    6. Als beheerder wil ik (voor web- en non-web-diensten) dat mutaties in identiteiten (b.v. "iemands dienstbetrekking wordt beëindigd bij instelling X") zo kort mogelijk na die mutatie gevolgen heeft voor waartoe die identiteit toegang krijgt, zodat gebruikers geen of zo kort mogelijk (nog) onterecht toegang hebben tot diensten/bronnen.
    7. Als beheerder wil ik over de juiste auditgegevens kunnen beschikken om b.v. te gebruiken in een security incident response, zodat ik kan bijdragen aan het voldoen aan wet- en regelgeving en een veilige omgeving.
    8. Als beheerder wil ik dat de persoon achter een identiteit te achterhalen is (b.v. door NIET gebruik van een transient en dus WEL gebruik van een persistent id), zodat ik bij problemen en vragen over acties of resources van een identiteit (evt met hulp van de SCZ-beheerder) contact kan opnemen met de betreffende persoon.
    9. Als beheerder wil ik hulpmiddelen zoals checklists en templates over welke afspraken ik moet maken met CO-managers, zodat het gebruik van mijn dienst via COmanage goed verloopt, o.a. op punten als facturatie, gebruik/toekenning/sturing van hoeveelheden resources, al dan niet CO-specifieke aangeleverde attributen, policies, AUPs etc.
    10. Als beheerder wil ik dat de SCZ-infrastructuur een gespecificeerde, op de architectuur afgestemde beschikbaarheid (availability) nastreeft, zodat toegang tot mijn resources zo min mogelijk wordt beperkt door onbeschikbaarheid van de SCZ-infrastructuur (indien ik voor elke authenticatie afhankelijk ben van SCZ dient beschikbaarheid hoger te zijn dan wanneer periodiek een LDAP-sync plaatsvindt en authenticatie in principe tegen de lokale LDAP plaatsvindt).

In de rol van identityprovider

    1. Als identity provider wil ik voldoende zekerheid en overzicht over de aard, voorwaarden, aansprakelijkheid van de dienst, bijvoorbeeld door implementatie van R&S en CoCo, zodat ik weet onder welke voorwaarden mijn studenten/medewerkers diensten gebruiken en wat de gemaakte afspraken/onderliggende afspraken zijn waardoor ik kan bepalen of dat strookt met mijn randvoorwaarden, regelgeving etc.

    2. Als identity provider wil ik de autorisatiecomponent van SURFconext kunnen gebruiken om de instellingspopulatie met toegang tot de dienst te kunnen scopen, zodat ik zelf kan bepalen wie wel en wie niet bij de SCZ-diensten kan via een account van mijn instelling.

    3. Als identity provider wil ik dat eind-gebruikers consent geven voor het delen van instellingsattributen, zodat ik weet en kan aantonen dat eind-gebruikers daar zelf mee instemmen.

In de rol van “orchestrator”

    1. Als research ICT afdeling van de instelling wil ik diensten kunnen bundelen en als 1 eindpunt kunnen aanbieden richting identity providers, zodat ik met zo min mogelijk werk voor mij ik onze diensten eenvoudig toegankelijk kan maken voor eind-gebruikers.

    2. Als research ICT afdeling van de instelling wil ik een centrale voorziening treffen waar onderzoekers een aanvraag voor een nieuwe CO kunnen doen. Die CO moet vervolgens voldoen aan het policy template van de instelling.

    3. Als aanbieder van een CO-platform wil ik de user-interface voor CO-managers zo simpel mogelijk maken en zorgen dat CO-managers alleen de opties zien die relevant voor ze zijn, zodat CO-managers zo eenvoudig mogelijk met het CO-platform kunnen werken.

    4. Als aanbieder van een CO-platform wil ik er voor zorgen dat alleen vanuit een instelling geauthoriseerde mensen een CO kunnen aanmaken. Dit heeft als doel om te voorkomen dat iemand een CO kan aanmaken waar geen diensten aan gekoppeld zijn, wegens het ontbreken van toestemming van koppelen vanuit de instelling.

User story session(s)

Op 9 januari 2018 organiseerde het SCZ-project een workshop om user stories te bespreken, aan te vullen etc. Daarbij werd ondermeer op flipovers met post-its gewerkt. De foto's daarvan zijn te vinden in deze SURFdrive-map. De notities en opmerkingen zijn in principe verwerkt in de user-stories . De slides die door de workshop-begeleider, René Scheffer van Stroomt, werden gebruikt zijn hier te vinden.

  • No labels

2 Comments

  1. Om een extra idee te krijgen van wat SCZ vooralsnog wil bieden, delen we hier de 'user stories' (in hoofdlijnen) waarvoor we met SCZ een oplossing willen bieden.
    Willen we dit in het Nederlands of in het Engels hebben?
    1. In het Nederlands. Om dezelfde reden dat we de user story-sessie in het Nederlands deden. Als we dit in het Engels doen vergroten we mi de kans op misverstanden en dat lijkt me voor user stories niet handig.