GSS-API
Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de
versiunea revizuită pe 22 noiembrie 2019; verificarea necesită
1 editare .
GSS-API ( GSS , GSSAPI , engleză Generic Security Services API , interfață de programare a serviciilor de securitate comună ) - API pentru accesarea serviciilor de securitate. Descris în standardul IETF . Conceput pentru a rezolva problema incompatibilității serviciilor de securitate similare.
Descriere
GSS-API în sine nu oferă servicii de securitate, ci oferă o interfață între aplicații și implementările GSSAPI (de obicei biblioteci). Aceste biblioteci oferă o interfață compatibilă GSS-API, permițându-vă să construiți aplicații care pot funcționa cu diferite biblioteci de securitate; permițând înlocuirea bibliotecilor fără a fi nevoie să rescrie aplicațiile.
O caracteristică distinctivă a aplicațiilor implementate folosind GSSAPI este utilizarea mesajelor private (token-uri) care ascund detaliile implementării din aplicațiile de nivel superior. Partea server și client a aplicațiilor sunt concepute pentru a interacționa folosind jetoane GSSAPI. Tokenurile pot fi de obicei transferate printr-o rețea (publică) nesigură. După ce părțile (client și server) au schimbat un anumit număr de mesaje, biblioteca GSSAPI informează ambele părți despre interacțiune cu privire la stabilirea unui context securizat .
Odată ce a fost stabilit un context securizat, mesajele de aplicație protejate pot fi „înfășurate” (criptate) utilizând GSSAPI pentru transmiterea securizată între server și client.
Aspecte tipice de securitate oferite de bibliotecile care implementează GSSAPI:
- confidențialitatea
- integritate
- autenticitatea ambelor părți ale schimbului de informații
GSSAPI descrie aproximativ 45 de apeluri. Principal:
- GSS_Acquire_cred - Obținerea unei dovezi de identitate a utilizatorului (cel mai adesea o cheie privată, o parolă)
- GSS_Import_name - conversia numelui utilizatorului, gazdei într-un formular care vă permite să definiți un obiect de securitate
- GSS_Init_sec_context - creează un token client pentru a-l trimite către server (de obicei, o provocare, în cadrul modelului de provocare-răspuns (autentificare) )
- GSS_Accept_sec_context - Gestionează un token creat cu GSS_Init_sec_context și returnează opțional un simbol de răspuns
- GSS_Wrap - Convertește datele aplicației într-un formular de mesaj securizat (de obicei criptare)
- GSS_Unwrap - extrage datele aplicației dintr-un mesaj protejat (de obicei decriptare)
GSSAPI a fost standardizat pentru C ( RFC 2744 ) și Java ( JSR-072 ).
Limitările GSSAPI includ faptul că standardizează doar autentificarea , nu autorizarea și că presupune o arhitectură client-server .
Anticipând apariția unor noi mecanisme de securitate, GSSAPI include un pseudo-mecanism special , SPNEGO , care permite descoperirea și utilizarea unor mecanisme care nu existau la momentul construirii aplicației.
Comunicarea cu Kerberos
GSSAPI este adesea folosit împreună cu Kerberos . Spre deosebire de GSSAPI, API-ul Kerberos nu este standardizat (și există API-uri incompatibile). GSSAPI vă permite să utilizați diferite implementări ale Kerberos fără a modifica codul aplicației.
Tehnologii înrudite
Termenii de bază GSSAPI
- Nume (nume) - un șir binar pentru a denota un identificator (nume utilizator, aplicație etc.) De exemplu, Kerberos folosește formatul „utilizator@REALM pentru utilizatori și serviciu/nume gazdă@REALM pentru aplicații.
- Acreditare (identitate) - informații care dovedesc autenticitatea unui obiect (de obicei o parolă sau o cheie privată).
- Context (context) - starea canalului de comunicare
- Token (token) - un mesaj opac (la aplicație) care este trimis în faza de stabilire a conexiunii sau în timpul transmiterii unui mesaj securizat
- Mecanism - Implementarea GSSAPI de bază care furnizează numele, identitatea și simbolurile reale. Mecanisme tipice: Kerberos, NTLM , DCE , SESAME , SPKM , LIPKEY .
- Inițiator / acceptor (inițiator / destinatar) - partea care trimite primul token este inițiatorul ; partea opusă este destinatarul . De obicei, receptorul este serverul, iar inițiatorul este clientul.
Istorie
- Iulie 1991: Grupul de lucru IETF CAT (Common Authentication Technology) sa întâlnit la Atlanta sub conducerea lui John Linn
- Septembrie 1993: GSSAPI versiunea 1 publicată ( RFC 1508 , RFC 1509 )
- Mai 1995: implementarea SSPI a fost lansată cu Windows NT 3.51
- Iunie 1996: Mecanismul Kerberos pentru GSSAPI a fost lansat ( RFC 1964 )
- Ianuarie 1997: GSSAPI versiunea 2 ( RFC 2078 )
- Octombrie 1997: standardul SASL publicat, inclusiv mecanismul GSSAPI ( RFC 2222 )
- Ianuarie 2000: Actualizarea 1 pentru GSSAPI versiunea 2 ( RFC 2743 , RFC 2744 )
- August 2004: reuniunea grupului de lucru KITTEN (continuarea CAT)
- Mai 2006: Utilizarea standardizată a GSSAPI pentru SSH ( RFC 4462 )
Vezi și
Link -uri