Viimeaikainen keskustelu Shibboleth-konsortion postilistalla ja aiemmassa artikkelissa viitattu tietoturvasuositus ovat tuoneet uuteen valoon SAML-vastauksen salaamisen. Shibboleth IdP -ohjelmiston pääkehittäjä on esittänyt näkemyksen, että henkilötietojen suojaamiseksi ainoat riittävät vaihtoehdot ovat: tiedon siirtäminen taustakanavalla suoraan palvelimien välillä (artifact) tai autentikaatiovastauksen assertion salaaminen.

Tämä mielipide heijastelee jo saml2int-profiilin luonnoksessa, johon on kirjattu IdP-palvelimelle vaatimukseksi:

In the event the HTTP-POST binding [SAML2Bind] is used, assertions MUST be encrypted and transmitted via a <saml:EncryptedAssertion> element. 

Hakassa HTTP-POST on ainoa sallittu yhteystapa autentikaatiovastauksen välittämiseen. Nyt luonnoksena esitetty profiili edellyttäisi jatkossa Hakassa SAML-viestien salaamista. Jatkossa pelkkä HTTPS ei riittäisi viestien suojaamiseen.

Nykyisin Hakassa SP:n on tuettava salausta, eli pystyttävä avaamaan salattu SAML-viesti. Tästä syystä Hakassa SP:n on rekisteröitävä metadataan varmenne. IdP:lle SAML-viestien salaaminen on vapaaehtoista. Koska SP:lle kyky salauksen purkuun on pakollista, on ollut IdP:n valittavissa, salataanko viestit vai ei.

Vaikka Hakassa ei olisi palveluja, jotka eivät tue salausta, operoinnin tiedossa on, että käytössä on paljon tuotteita, joilla ei ole kykyä tukea salattuja SAML-viestejä. Hakaan liitetyillä IdP-palvelimilla voi olla kahdenvälisiä luottosuhteita tällaisille palveluille. Jos salaus Hakassa tulee pakolliseksi, IdP:n on luontevaa kytkeä salaus päälle kategorisesti kaikkien palvelujen osalta. IdP:n konfiguraatiossa on mahdollista tehdä poikkeussääntö ja jättää viestit salaamatta sellaisille palveluille, jotka salausta ei tue, jos se on organisaation toimintokäytänteiden mukaista.

Haka-operointi suosittaa jo etupainotteisesti kartoittamaan muutoksen vaikutuksia organisaation kertakirjautumiselle ja kytkemään SAML-viestien salauksen kategorisesti päälle IdP:palvelimella heti, kun mahdollista.


Lisätietoa:


Briefly in english

Recent discussion implicates to encryption of SAML-assertions becoming mandatory in Haka. Please see relevant discussion in Shibboleth mailing list and the draft document for new version of saml2int-profile.

  • No labels

1 Comment

  1. Shibboleth IdP -ohjelmistossa salaaminen sekä vastauksen allekirjoittaminen ovat oletusarvoisesti päällä. Jos nämä on konfiguraatiosta ottanut pois käytöstä, tulee nämä nyt ottaa takaisin käyttöön.

    Tiedosto conf/relying-party.xml

    Esimerkiksi jos kyseessä oletusprofiili "<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">". Tämän beanin sisällä olevasta SAML2.SSO profiilista voi varmistaa että seuraavia optioita ei ole asetettu pois käytöstä ('false'). Nämä optiot voi poistaa kokonaan ja käyttää oletusarvoja (signResponses on optional, mutta myös suositeltavaa ottaa käyttöön).

    • p:encryptAssertions="false" (poistetaan asetus / tai asetetaan "true")
    • p:signResponses="false" (poistetaan asetus / tai asetetaan "true")

    Oletuskonfiguraatiossa Hakassa poiketaan assertion allekirjoituksella, samalla on siis hyvä tarkistaa että seuraava optio on päällä.

    • p:signAssertions="true" (Lisätään asetus)

    Yksinkertaisimmillaan tämä SAML.SSO profiilin rivi voisi näyttää seuraavanlaiselta

    • <bean parent="SAML2.SSO" p:postAuthenticationFlows="attribute-release" p:signAssertions="true"/>

    Jos joidenkin palveluiden kanssa tulee ongelmia, joita Hakaan kuuluvien SP:den kanssa ei pitäisi tulla. Tällöin voidaan tehdä poikkeussäännöstöt vaikka entityid kohtaisesti. Esimerkki tämän tekemiseen löytyy kyseisen tiedoston lopusta, kommentoituna.

    Lisätietoa: