ATK-miehen autistiset seikkailut Graph API:n luvituksien kanssa – Kootut pelkotilat
Tätä proosaa kirjoittaessa Suomen demokraattinen kansanvalta laskeutuu kohti kristillisiä juhlapyhiä, joten pyydän sallivuuttanne kirjallisessa ilmaisussani kohti pelkotilojani.
Kuten on perinteeksi muodostunut, niin myös tätä peijoonia lähestytään ihan fiktiivisen esimerkin kautta:
Olet se ainoa ATK:sta ja pilvestä vähän ymmärtävä teknikko Reijon Raskasmetallipajalla ja kas sekä kummaa; raskasmetallipajan bisnes on käynyt omalla harkinnalla ja päissään shoppailemassa uuden SaaS-ratkaisun, jolla käsitellään sähköpostin kautta saapuvia reklamaatioita.
Eli käytännössä himmelillä on maililaatikko, johon luvitetaan SaaS-ratkaisun lonkerot. Maililaatikosta ratkaisu lukee, sekä automaattisesti sortteeraa saapuvien mailien PDF-liitetiedostot eteenpäin SaaS-ratkaisun syövereihin.
Ja koska olet aikaasi seuraava ATK-jamppa, tajuat ettei tässä lonkeroinnissa boksiin voi hyödyntää pystyynkuollutta IMAP:ia mitenkään järkevästi.
…Joten
Toimittajan valkopaperissa, eli ohjeessa, kuvataan luvituksen toimivan näin, ja nämähän hilppeet löytyvät API permissioineiden alta:
Admin consentti perään ja hymiö, homma valmis ja ikuiselle kahvitauolle takaisin?
ATK-miehen autismiviisarit alkavat tässä kohden vähän värisemään, joten palataan speksin äärelle ja kappas! Lonkerot halutaan vain yhteen shared mailboxiin ja tarkoitus sielläkin olisi vain saada luettua, siirrettyä eteenpäin PDF-liite ja manipuloitua sähköposti arkistokansioon.
Joten, katkotaan vähän jalkoja API-luvilta
Mutta, autismivärähtely ei vielä ota laantuakseen, koska ATK-jätkä haluaisi seuraavaksi rajoittaa tämän lonkeroinnin vain yhteen ennakolta tiedossa olevaan shared boxiin.
Tuunaillaan vähän vielä:
Vaikkakaan tämä appi-julkaisu ei tuota mitään sellaista hyvää, mihin loppukäyttäjät voisivat kirjautua, niin silti, vedetään nämä napit asentoihin njet
Ja assignataan hyödyntäjät, joko security groupilla tai ihan sellaisinaan kohtaan users and groups.
Ollaanko nyt maalissa iskä? Nope
Jostakin kosmisesta syystä kykenet tekemään seuraavan tempauksen vain osittain graafisten hallintapaneelistojen kautta.
Eli tempauksen nimi on loihtia sellaiset raja-aidat appi-julkaisulle, että appi pystyy ihan aikuisten oikeasti lonkeroitumaan vain yhteen ja tiedossa olevaan shared mailboxiin, eikä (niin halutessaan) kaikkiin tenantin sharedeihin.
Aloittakaamme tämä pyhä tempaus Exchange Onlinesta, josta summonoimme käyttöömme vanhanliiton mail-enabled security groupin, jolle kastamme myös jonkin selkeän nimen:
Hyödymme mail-enabled security grouppia, koska esmes M365-groupilla et voi tätä puljausta tehdä.
Kun selkeästi nimikoitu ryhmä on hänessä, eli Exchange Onlinessa, liität siihen sen SaaS-palvelun hyödyntämän shared mailboxin kiinni eli gines.
Sitten avaat roskistulipaloksikin kutsutun Exchange Powershellisi ja liityt tenusi tajunnanvirtaan.
Ja vedät ulkomuistista seuraavan onelinerin tuotantoon:
New-ApplicationAccessPolicy -AppId 'TÄHÄN TULEE APP-REKKAUKSEN ID' -PolicyScopeGroupId
'TÄHÄN TULEE MAIL-ENABLED SECURITY GROUPIN SMTP-OSOITE' -AccessRight RestrictAccess
-Description "TÄHÄN RAKAS ADMINI KUVAAT MITÄ HELVETTIÄ TÄMÄ ACCESS POLICY TEKEE"
Mail-enabled security groupin jäsenistöstä et myöskään saa loihdittua dynaamisella säännöllä, mutta tässä esimerkissä se ei haittaa, koska app-rekisteröinti hyödyntää vain yhtä lootaa.
Ja vasta tämän jälkeen autismin jännittävä kirjo saa pitää hetkellisen paussin.
Jos paranoidisuus ja luotto SaaS-kauppiaaseen on edelleenkin vähän siinä ja tässä, niin mikään ei estä sinua tekemästä vielä CA-sääntöä
Toki pätevän CA-säännön teko edellyttää, että tunnet SaaS-ratkaisun mielenterveyden rakenteen vähän tarkemmin ja shared mailboxin hyödyntäminen palvelupinossa aiheuttaa CA:n vinkkelistä vähän pohdittavaa.
Näihin kuviin ja tunnelmiin nauttimaan vuoden 2023 DLC-kokemuksista.
