Single Sign On ja sinä – Säästetään ihan kaikilta liiketoiminta-aikaa järkeviin asioihin
Ahoy ahoy! Tässä fantasiaskenaariossa olet pohjoismaisessa keskisuuressa yrityksessä se ainoa ATKoota taitava monikanttinen henkilöoletettu. M365-tuottavuustilbehöörien lisäksi keskeiset IT-konstruktiot ovat
- Efecte IT-palveluhallintatuote
- Basware P2P, ostolaskujen käsittelyssä ja tiliöinnissä
- SAP Fiori, laukaisualustana mm. firman S4/HANA -ratkaisuihin ja appisiin. Eli erppi-härveli
- GitHub, devops-jeesusten multiplayer notepad ja prod commit kaaospainikkeet.
Näiden lisäksi on paikalliseen pizzaboxiin hostattu parisen raikasta tuulahdusta 90-luvulta, joissa taikasanana on COBOL.
Yllättäen aivan jokaiseen oheisjärjestelmään on omat luvitusprosessinsa ja pääsynhallintaproseduurinsa. Tämä aiheuttaa kohtalaisen paljon työkuormaa IT-bunkkerissa, varsinkin kosteiden kesälomasesonkien jälkeen, joiden aikana on useampikin valkokauluri onnistunut hivelemään sitä henkistä resetti-painiketta oikeinkin tehokkaasti.
Kevyen tieteellisen pohdinnan jälkeen päädyt esittämään ylimörökölleille ja rahakirstun vartijoille, että ensisyksystä alkaen ainakin nuo moternit SaaS-ratkaisut viedään SSO-menettelyn taakse, jolloin Azuren identiteetistä syntyy se ainut muistamisen arvoinen tekijä.
Paikalliset vintage-palvelut rajasit nokkelasti heti kättelyssä tämän ensimmäisen aallon ulkopuolelle, koska niiden user management on dokumentoimatonta salatiedettä täysin merkkipohjaisen suurkone-emulaation kautta.
Hankkeen lisäboonuksena kovettuu myös ym. SaaS-himmeleiden pääsynhallinta, nimittäin proggiksen jälkeen voit määritellä niiden käyttöön ehdollista pääsynhallintaa (conditional access) fantastisilla reunaehdollaisi. Esim. corp-verkon ulkopuolella vaadit MFA-tunnistautumista ja complianttia työasemaa Fiorin appisiin.
Disclaimer
Trusted networkseihin ja niiden näkyviin liityntäpisteisiin nojautuminen pääsynhallinnallisissa ratkaisuissa eivät ole aivan tätä päivää, mutta joskus pakollista pahaa. Modernit pääsynhallintaratkaisut nojautuvat enemmän session, identiteetin ja päätelaitteen arviointiin vasten sääntöpatteristoasi.
Cloud Application Administrator-päähine päähän ja konffihommiin.
Eikusta hetkinen! Tässä kohden olisi hyvä löytää se paritanssin partneri sovellusasiantuntijan suuntimoilta; sellainen taikuri, joka tietää ja tuntee, sekä kykenee tekemään tarvittavia muutoksia itse kohdesovelluksen päädystä. Nimittäin usein SSO on kahden eri järjestelmän tango. Keskeisesti pitäisi ainakin pystyä mappaamaan, mitä samaa on Azuren ja kohdejärjestelmän käyttäjäidentiteeteissä.
Oletetaan nyt, että tanssipartnerit ovat löytyneet ja hankkeella on hymiöllä varustettu hyväksyntä hut gangstereilta, eli liiketoimintajohdolta.
Tässä skenaariossa ei myöskään ole käytössä paikallista aktiivihakemistoa tai federaatiopalveluille tarvetta. COBOL-helvetti pyörii ihan omassa ympäristössään ja realmissaan, etkä oikeasti halua koskea siihen tämän hankkeen puitteissa.
Koska tämän blokirykäisyn lukijoilla on rajatusti aikaa työelämässään tutustua insultin hengentuotoksiin, niin puljataan yhdessä Fiorin veräjät kondariin, eli jiiriin, eli kuoseihin. Weapon of choice uksen avaukseen on lopulta SAML 2.0-perustainen claimi JA onneksi et koskaan tullut puljanneeksi reverse proxyä tähän väliin. SAML:n moodiksi myös näperrellään front-channel comm.
Hommahan alkaa uuden Enterprise Appisen julkaisusta Azureesi, koska puhutaan kohtalaisen valtavirran kilkuttimesta, niin listoilla pitäisi olla valmiina SAP Netweaver tai SAP Fiori, tässä kontekstissa ei ole väliä kumman valkkaat, mutta valkkaat kuitenkin SAP Fiorin. JA, koska en ole nähnyt ikinä yhtään SAP-järjestelmää, joka pyörii vain prodin varassa, niin merkkaat fiksusti, onko nyt kyseessä dev, acceptance vai peräti prod -ympäristöön tarkoitettu julkaisu.
Tämän jälkeen luvitat halutut käyttäjät etupeltoon tähän huikeaan julkaisuun. Voit esim. hyödyntää dynaamisia sääntöjä, että kaikki ne, joilla on powerBI:n oikeuttava lisenssi, ovat myös oikeutettuja käyttämään tätä julkaisua.
Sittenpä etsit siitä vasemmalta kohdasta Manage kohdan Single sign-on ja SAML. Liität tähän Service Provider identity and urlit liittyen käsittelyyn Fiorin osalta. Tässä kohtaa on se hyvä tanssipartneri painonsa arvosta jalometalleja, koska näitä ei vain puhtaasti Azuren-mies voi tietää kylmiltään.
The Identifier (Entity ID) ja ACS (Assertion Consumer Service) urlit. Tässä konffin vaiheessa pitää tietää mm. SAP client number, mihin siis pointataan tämä claimi menemään, esim. 12(dev), 24(acceptance) tai 666(prod).
Editoidaan basic SAML conffeja sitten ja tähän tarvitset vahvaa taustatukea myös rikoskumppaniltasi.
Kahvipaussin jälkeen alkaa ehkä vaikein osuus koko hankkeesta, eli user attributes & claims. SAP nimittäin odottaa aika tarkkaa syntaksia assertioiden osalta. Toki tässä kohden havahdut siihen, että SAP:n user basen vanilla-identiteetit ovat mallia U1234567, kun taasen Azure haluaisin oletuksineen pelata UPN:n kanssa, tai tarkemmin, vanillana claim-tiketissä pusketaan username, email addrs, first name ja last name -tietoja.
Hyödynnämme siis tässä skenaariossa claim transformaatiota, eli editoidaan sitä. Claim Name Unique User Identifier (Name ID) ja käytetään siinä Transformation ExtractMailPrefix() user.userprincipalnameen.
Tämän humpan jälkeen otat alas sertifikaatin ja federaatio metadatan määrittely XML:n. Näitä tarvitsee myöhemmissä vaiheissa SAP-jeesus, kun varsinainen työ aloitetaan SAP:n konepellin alla. Vaikka itse en ole järin innoissani base64-levelin sertistä, niin käytetään sitä kuitenkin tässä esimerkissä.
Sitten päästät SAP-henkilöoletetun irti ja ohjeistat häntä Create SAML 2.0 local providerin suuntimoihin ja huomioitat häntä Identity Provider Discovery: Common Domain Cookie=automatic.
Lisäksi Azure AD tulee määrittää trusted provideriksi, jonka yhteydessä generoimasi XML-määritykset tunkataan SAP:n konepellin alle sertin kera. Tässä blogissa ei käsitellä tämän enempää SAP:n sielunmaisemaa, koska allekirjoittanut on ehkä valtakunnan viidenneksi heikoin esitys SAP-adminoinnissa.
Hyvä on kuitenkin pitää mielessä, että Azure AD:ssa olisi kiva olla myös SAP:n user basessa idioomi ja koska hyödynsimme claim transformaatiota tiketin mankeloinnissa, pitää muistaa hyväksyä default User ID mapping mode as Logon ID.
Jos SAP-leijonakuningas on kuitenkin poikkeuksellisen reippaalla mielentilalla, niin SAP user basessa voi hyödyntää myös käyttäjätunnuksien alias-kenttää, eli U12345678 -tunnuksen alias-kentässä on reijo.kylma@nyrkkipaja.fi (esimerkki, älä käytä); tällöin pitää huomioida User ID mapping moden vaihto Logon Alias -muotoon.
Kun kaikki on sanottu ja tehty, niin testaukset saavat alkaa. Kaiken mennessä oikein, päjähtää tutun SAP logonurlista Microsoftin kirjautumisikkuna, jonka olet toivottavasti korporaatiokuvastanut näyttämään kivalle.
Jos välissä tosiaan on se sangen yleinen reverssi-välityspalvelin, kuten Citrixin Netscaleri, niin tällöin pitää taivuttaa vähän enemmän konfiguraatiota. Näissä skenaarioissa kompastellaan yleensä protokollaan muunnoksissa paluupaketin osalta; useimmissa SAP-konfiguraatioissa on helpohkoa liputtaa paluupaketin mode switchin olevan ihan ookoo tavaraa.
Summaten siis:
SSO on erittäin hyödykäs lisä moderniin työpaikkaan, joka osaltaan mahdollistaa paremman käyttäjien liikehdinnän auditoimisen, conditional access -säännöstöjen hyödyntämisen ja toki myös rimpuilun ulos kymmenien eri käyttäjätunnuksien ihmeellisestä maailmasta loppukäyttäjän vinkkelistä.
Azure-admini ei kykene yksin vetämään näitä hankkeita, vaan hän tarvitsee reissukaveriksi sovellusasiantuntijan.
Varaudu t-shoottisessioihin ihan ajan kanssa, koska käytettävyyteen voi joskus ottaa kantaa mm. corp-verkon topologiat yms. jekut.
SAP-esimerkistä jätettiin pois kokonaan uusien käyttäjien provisiointi suoraan Azuren kautta. Tämä on mahdollista esim. GitHubin kanssa toteutettuun yhteiseloon, mutta SAP-maailmassa en ole koskaan törmännyt Azuren kautta provisioituihin käyttäjiin. Tämä, koska SAP:n autorisointimaailma on ihan omanlaisensa peto, jota hanskataan SAP:n kannalta yllättäen ihan omasta näkymästään konsolidoidusti.
Näihin kuviin ja tunnelmiin siirrymme ensi kerran odotteluun, jolloin turvallisesti siirrämme Azuren käyttäjätietoihin liittyvää hyvää kolmannen osapuolen järjestelmään.
– Pilvipalvoja Kai Kolima
