Autentikointiprotokollat:
Käyttäjien todennus sovelluksissa on yksi IT-osaston suurimmista nykyisistä haasteista. On paljon erilaisia järjestelmiä, joihin käyttäjän on päästävä käsiksi, ja siksi useimmat todennusprotokollat ovat tyypillisesti avoimia standardeja.
Lukemalla todennusprotokollia koskevia kysymyksiä Stack Overflow’sta käy melko selväksi, että aihe voi olla hämmentävä ja ylivoimainen.
Tässä blogikirjoituksessa esittelemme viisi yleisimmin käytettyä todennusprotokollaa ja selitämme, miten ne toimivat ja mitkä ovat niiden edut.
LDAP
LDAP (Lightweight Directory Access Protocol) on ohjelmistoprotokolla, jonka avulla kuka tahansa voi paikantaa organisaatioita, henkilöitä ja muita resursseja, kuten tiedostoja ja laitteita, verkossa, olipa kyse sitten julkisesta Internetistä tai yrityksen intranetistä.
Voidaan sanoa, että LDAP:sta on tullut suosittu ohjelma. Se toimi perustana, jonka varaan Microsoft rakensi Active Directoryn, ja sillä on ollut tärkeä rooli nykyisten pilvipohjaisten hakemistojen (tunnetaan myös nimellä Directories-as-a-Service) kehittämisessä.
LDAP lähettää palvelimien ja asiakassovellusten välisiä viestejä, joihin voi sisältyä kaikenlaista asiakaspyynnöistä tietojen muotoiluun.
Toiminnallisella tasolla LDAP toimii sitomalla LDAP-käyttäjä LDAP-palvelimeen. Asiakas lähettää toimintopyynnön, jossa pyydetään tiettyjä tietoja, kuten käyttäjän kirjautumistietoja tai muita organisaatiotietoja. LDAP-palvelin käsittelee sitten kyselyn sisäisen kielensä perusteella, kommunikoi tarvittaessa hakemistopalveluiden kanssa ja vastaa. Kun asiakas vastaanottaa vastauksen, se irrottautuu palvelimesta ja käsittelee tiedot sen mukaisesti.
Hanki johtajantuotto-oppaamme MSP-yrityksille
Opi lisää siitä, miten voit menestyksekkäästi luoda johtolankoja ja skaalautua
Go oppaaseen
Kerberos
Kerberos on verkon todennusprotokolla. Se on suunniteltu tarjoamaan vahvaa todennusta asiakas-palvelinsovelluksille käyttämällä salaisen avaimen kryptografiaa. Tämän protokollan ilmainen toteutus on saatavilla Massachusetts Institute of Technologysta. Kerberos on saatavilla myös monissa kaupallisissa tuotteissa.
Tässä ovat yksinkertaisimmat vaiheet, jotka suoritetaan todennusta varten Kerber-pohjaisessa ympäristössä.
- Asiakas pyytää todennuslippua (TGT) avainten jakelukeskukselta (KDC, Key Distribution Center).
- KDC tarkistaa tunnistetiedot ja lähettää takaisin salatun TGT:n ja istunto-avaimen.
- Asiakas pyytää päästä käsiksi palvelimella olevaan sovellukseen. KDC:lle lähetetään sovelluspalvelimelle lippupyyntö, joka koostuu asiakkaan TGT:stä ja todentajasta.
- KDC palauttaa käyttäjälle lipun ja istuntoavaimen.
- Lippu lähetetään sovelluspalvelimelle. Kun lippu ja todentaja on vastaanotettu, palvelin voi todentaa asiakkaan.
- Palvelin vastaa asiakkaalle toisella todentajalla. Saatuaan tämän todentajan asiakas voi todentaa palvelimen.
Oauth 2
OAuth 2 on auktorisointikehys, jonka avulla sovellukset voivat saada rajoitetun pääsyn HTTP-palvelun, kuten Facebookin, GitHubin ja DigitalOceanin, käyttäjätileihin.
Tässä on kuvaus valtuutusprosessin perusvaiheista:
- Sovellus pyytää käyttäjältä lupaa käyttää palvelun resursseja.
- Jos käyttäjä hyväksyy, sovellus saa valtuutusluvan.
- Sovellus pyytää valtuutuspalvelimelta (sovellusrajapinta (API)) käyttöoikeustunnuksen. Tämä tapahtuu esittämällä identiteettinsä ja auktorisointiavustus.
- Jos sovelluksen identiteetti on todennettu ja auktorisointiavustus on kelvollinen, API antaa sovellukselle access tokenin. Valtuutus on valmis.
- Sovellus pyytää resurssia API:lta ja esittää käyttöoikeustunnisteen todennusta varten.
- Jos käyttöoikeustunniste on kelvollinen, API tarjoilee resurssin sovellukselle.
SAML
Security Assertion Markup Language (SAML) on XML-pohjainen avoimen standardin mukainen tietomuoto osapuolten väliseen todennus- ja valtuutustietojen vaihtoon, erityisesti identiteetin tarjoajan ja palveluntarjoajan välillä. SAML on OASIS Security Services Technical Committee:n tuote.
JumpCloud on yksi parhaista Single Sign-On (SSO) -palveluntarjoajista, joka tukee SAML-todennusprotokollia. JumpCloudin SSO tarjoaa SAML-integraatioita 700 suositun yrityssovelluksen kanssa (mukaan lukien Kisi) ja automatisoituja käyttäjän elinkaaren hallintaominaisuuksia, kuten Just-in-Time (JIT) provisioning ja SCIM provisioning/deprovisioning.
Tässä on kuvaus autentikointiprosessin tyypillisistä vaiheista:
- Käyttäjä käyttää etäsovellusta intranetissä tai vastaavassa olevan linkin avulla, ja sovellus latautuu.
- Sovellus tunnistaa käyttäjän alkuperän (sovelluksen aladomainin, käyttäjän IP-osoitteen tai vastaavan perusteella). Se ohjaa käyttäjän takaisin identiteettipalveluntarjoajalle ja pyytää todennusta.
- Käyttäjällä on joko olemassa oleva aktiivinen selainistunto identiteettipalveluntarjoajan kanssa tai hän luo sellaisen kirjautumalla identiteettipalveluntarjoajalle.
- Tunnistuspalveluntarjoaja rakentaa todennusvastauksen XML-dokumentin muodossa, joka sisältää käyttäjän käyttäjänimen tai sähköpostiosoitteen. Tämä allekirjoitetaan X.509-asiakirjan avulla. varmenteella ja lähetetään sitten palveluntarjoajalle.
- Palveluntarjoaja (joka jo tuntee identiteettipalveluntarjoajan ja jolla on varmenteen sormenjälki) noutaa todennusvastauksen ja validoi sen varmenteen sormenjäljen avulla.
- Käyttäjän identiteetti on varmistettu, ja käyttäjälle annetaan sovelluksen käyttöoikeus.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) on verkkoprotokolla, joka tarjoaa keskitetyn todennuksen, valtuutuksen ja kirjanpidon (AAA tai Triple A) hallinnan käyttäjille, jotka muodostavat yhteyden verkkopalveluun ja käyttävät verkkopalvelua.
RADIUS:n todennus aloitetaan, kun käyttäjä pyytää pääsyä verkkoresurssiin etäyhteyskäyttäjapalvelimen kautta. Käyttäjä syöttää käyttäjänimen ja salasanan, jotka RADIUS-palvelin salaa, ennen kuin ne lähetetään todennusprosessin läpi.
Sitten RADIUS-palvelin tarkistaa tietojen paikkansapitävyyden käyttämällä todennusjärjestelmiä tietojen tarkistamiseksi. Tämä tehdään vertaamalla käyttäjän antamia tietoja paikallisesti tallennettuun tietokantaan tai viittaamalla ulkoisiin lähteisiin, kuten Active Directory -palvelimiin.
RADIUS-palvelin vastaa sitten hyväksymällä, haastamalla tai hylkäämällä käyttäjän. Yksittäisille käyttäjille voidaan myöntää rajoitettu käyttöoikeus vaikuttamatta muihin käyttäjiin. Kun kyseessä on haaste, RADIUS-palvelin pyytää käyttäjältä lisätietoja käyttäjätunnuksen tarkistamiseksi, joka voi olla PIN-koodi tai toissijainen salasana. Hylkäämisen tapauksessa käyttäjältä evätään ehdoitta kaikki RADIUS-protokollan käyttöoikeudet.
Minkä siis valita?
LDAP, Kerberos, OAuth2, SAML ja RADIUS ovat kaikki käyttökelpoisia erilaisiin valtuutus- ja todennustarkoituksiin, ja niitä käytetään usein SSO:n kanssa.
Valitsemasi protokollan on heijastettava sovelluksesi tarpeita ja sitä, millaista olemassa olevaa infrastruktuuria on olemassa. On hyödyllistä valita yksinkertainen ja standardoitu ratkaisu, jolla vältetään kiertotöiden käyttö yhteentoimivuuden varmistamiseksi natiivien sovellusten kanssa. Siksi SAML on hyvä valinta, sillä se integroituu JumpCloudin SSO:n ja 700 suositun yrityssovelluksen kanssa.
Jos etsit lisää SSO:hon liittyvää sisältöä, voit tutustua oppaaseemme siitä, miten päätät, minkä tyyppistä kertakirjautumista voit käyttää.
Relevantit linkit
- Fyysisen turvallisuuden arviointi | Parhaat käytännöt &Auditointiprosessi
- Mitä on IoT – Määritelmiä alan asiantuntijoilta
- Identiteettien pääsynhallintatyökalut (Identity Access Management (IAM) Tools)