Asiakkaan tunnistusratkaisun toteuttamisen yhteydessä teimme äskettäin havainnon:
Microsoft tulkitsee mielenkiintoisesti Azure AD -palvelussaan OpenId Connect -tunnistamisessa id_tokenissa luovutettavan iss claimin merkityksen.
On vaikea perustella saati väittää, että Microsoftin tulkinta claim:n arvosta olisi väärä. Tapaus johti kuitenkin siihen, että WeAren oli tarkistettava omaa tulkintaansa aina tunnistusratkaisun toteutuksen lähdekoodiin asti. Ratkaisun toteutuksesta julkaistiin äskettäin asiakkaille uusi versio, jossa molemmat erilaiset tulkinnat on huomioitu.
OIDC Coren tulkinta
Nyt puheena olevassa tarkoituksessa iss claimia käytetään id_tokenissa, jolla käyttäjän henkilötietoja luovutetaan tunnistustapahtuman yhteydessä siltä osin, kuin niitä ei luovuteta userInfo-rajapinnasta. Iss claim kuvataan OIDC Core -märityksessä näin:
Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
Tulkintaa tarkennetaan kappaleessa, jossa kuvataan, miten tunnistukseen luottavan osapuolen (RP) kuuluu varmentaa, että sen vastaanottama id_token on pätevä:
The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.
Ylläolevasta tarkennuksesta voisi johtaa sen tulkinnan, että id_tokenissa luovutettavan iss claimin arvo on oltava täsmälleen sama, joka OP:sta on julkaistu aiemmin mainitussa OP:n metadata-dokumentissa OIDC Discovery profiilin mukaisesti.
Hassuksi voisi kuvailla sitä, että jo OIDC Core määritystä kirjoitettaessa on huomattu, että arvon merkityksen tulkintaan liittyy teknisiä erimielisyyksiä.
Implementers may want to be aware that, as of the time of this writing, Google's deployed OpenID Connect implementation issues ID Tokens that omit the required https:// scheme prefix from the iss (issuer) Claim Value.
Microsoftin tulkinta
Microsoft tulkitsee Azure AD palvelussaan asiaa hieman toisin. Azure AD:ssa on mahdollista kutsua tenantin varsinaisten (member) käyttäjien lisäksi vieraskäyttäjiä (guest) toisista tenanteista. Vieraat saavat yksilöllisen tunnisteen, joka perustuu heidän tunnisteeseensa omassa isäntä-tenantissan. Vieraat käyttävät oman isäntä-tenantinsa salasanaa kirjautuessaan myös niiden tenantien palveluihin, joissa ovat vieraaksi kutsuttuna.
Kun vieraskäyttäjä kirjautuu käyttäen vieras-tenantin Azure OP -instanssia, id_tokenissa hänestä ei luovutetakaan kyseisen OP:n metadatan issuer claimin mukaista iss arvoa, vaan hänen alkuperäisen isäntä-tenantinsa metadatan issuer claimin arvo.
Toteutus on täsmälleen, kun Microsoft on kuvannut sen omassa dokumentaatiossaan:
Identifies the issuer, or "authorization server" that constructs and returns the token. It also identifies the Azure AD tenant for which the user was authenticated.
Microsoft tarjoaa edellisen dokumentin lisäksi näkemyksensä tokenin pätevyyden tarkastamisesta OIDC Core -määrityksen tapaan:
In OpenID Connect, the issuer claim ("iss") identifies the IDP that issued the ID token. Part of the OIDC authentication flow is to verify that the issuer claim matches the actual issuer. The OIDC middleware handles this for you.
Ohjeesta voi päätellä Microsoftin kehittäjän ajatelleen, että ohjelmistokehittäjien ei edes pitäisi pohtia asioita tällä tasolla, vaan luottaa sen omaan väliohjelmistoon. Microsoft on tässä pitkälti oikeassa. On suuri virheiden mahdollisuus, kun perehtymätön alkaa tulkita määrityksiä ja toteuttaa ohjelmistoja näiden tulkintojen pohjalta.
Samantyyppisiä ajatuksia esitetään asiaan liittyen myös verkon kysymys- ja keskustelupalstoilla sen enempää pohtimatta, mitä varsinaisen määrityksen kirjoittaja on alun perin tarkoittanut. Eräs esimerkki on tässä blogikirjoituksessa.
Kuitenkin on niin, että myös Microsoftin palveluja on voitava käyttää muilla kun sen itsensä tarjoamilla ohjelmistoilla.
Nimbus-kirjaston toimintatapa
WeAre Solutions käyttää mallien mukaisesti Nimbus-kirjastoa id_tokenin pätevyyden tarkastamiseen. Kirjasto toteuttaa näppärän IDTokenValidator-luokan, jonka validointi perustuu siihen, että validaattorille annetaan instanssia perustettaessa iss claimissa sallittu arvo. WeAre:n toteutus perustui aiemmin mainittuun oletukseen. Validaattorille annettiin vertailtavaksi OP:n metadatan Issuer claimin arvo. Kuten todettu, tämä ei toimi yhteen Microsoft Azure AD:n tulkinnan kanssa.
Ei ole yhtä oikeaa totuutta
Tämä kokemus osoitti uudelleen jo aiemmin opitun.
Microsoft tulkitsee mielenkiintoisesti Azure AD -palvelussaan OpenId Connect -tunnistamisessa id_tokenissa luovutettavan iss claimin merkityksen.
Ihmiset kirjoittavat määritykset ja niitä tulkitsevat ihmiset. Kahden keskeisenkin toimijan tulkinta yksittäisestä yksityiskohdasta voi olla erilainen.
Tämä tapaus osaltaan korostaa yhteensopivuustestauksen merkitystä. Aina kahden eri järjestelmän yhteen sovittamisen yhteydessä täytyy varmistua vähintään yleisimpien käyttötapausten kautta, että järjestelmät ovat todella yhteen toimivia.
Vaikka testauksessa olisikin tunnollinen ja kattava, on silti hyväksyttävä, että jokin testitapaus saattaa asiantuntijoilta jäädä huomaamatta. Ajan kuluessa myös tulkinnat ja toteutukset muuttuvat. Yhteensopivuusongelmia saattaa esiintyä vielä päivityksien yhteydessä jatkuvan palvelun ollessa tuotannossa.
Ohjelmistotuotannossa pitäisi noudattaa jatkuvan testaamisen käytäntöä, jossa jokainen pieninkin ohjelmistokomponentti ja muutos on yksikkötesteillä kuvattu. Tällä vältetään regressio-ongelmia, joita saattaa esiintyä uusia ominaisuuksia tai muita muutoksia toteutettaessa, ellei koodi ole kattavasti testattu.
WeAren tunnistuspalvelu
WeAre on toteuttanut oman tunnistuspalvelun (IdP), joka on OpenId Connect (OIDC) ja SAML2 -tunnistuskäytänteitä toteuttava palvelu, joka tunnistaa käyttäjät mahdollistaen heidän pääsynsä järjestelmiin ja sovelluksiin. IdP:n avulla voidaan toteuttaa kertakirjautuminen (Single Sign On – SSO), jonka avulla käyttäjä pääsee yhden tunnistustapahtuman perusteella käyttämään kaikkia tunnistamisen piiriin kuuluvia sovelluksia ilman eri tunnistautumista. IdP on toteutettu avoimen lähdekoodin Shibboleth Identity Provider -ohjelmistolla.
