GSS-API
Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den
version , der blev gennemgået den 22. november 2019; verifikation kræver
1 redigering .
GSS-API ( GSS , GSSAPI , engelsk Generic Security Services API , fælles programmeringsgrænseflade for sikkerhedstjenester) - API til adgang til sikkerhedstjenester. Beskrevet i IETF- standarden . Designet til at løse problemet med inkompatibilitet af lignende sikkerhedstjenester.
Beskrivelse
GSS-API'en selv leverer ikke sikkerhedstjenester, i stedet giver den en grænseflade mellem applikationer og GSSAPI-implementeringer (normalt biblioteker). Disse biblioteker giver en GSS-API-kompatibel grænseflade, så du kan bygge applikationer, der kan arbejde med forskellige sikkerhedsbiblioteker; giver mulighed for at udskifte biblioteker uden at skulle omskrive applikationer.
Et karakteristisk træk ved applikationer implementeret ved hjælp af GSSAPI er brugen af private beskeder (tokens), der skjuler implementeringsdetaljer fra applikationer på højere niveau. Server- og klientsiden af applikationerne er designet til at interagere ved hjælp af GSSAPI-tokens. Tokens kan normalt overføres over et usikkert (offentligt) netværk. Efter at parterne (klient og server) har udvekslet et vist antal meddelelser, informerer GSSAPI-biblioteket begge parter om interaktionen om etableringen af en sikker kontekst .
Når en sikker kontekst er blevet etableret, kan beskyttede applikationsmeddelelser "pakkes" (krypteres) ved hjælp af GSSAPI til sikker transmission mellem server og klient.
Typiske sikkerhedsaspekter leveret af biblioteker, der implementerer GSSAPI:
- fortrolighed
- integritet
- ægtheden af begge sider af informationsudvekslingen
GSSAPI beskriver cirka 45 opkald. Hoved:
- GSS_Acquire_cred - Indhentning af et brugerbevis på identitet (oftest en privat nøgle, adgangskode)
- GSS_Import_name - konvertering af navnet på brugeren, værten til en formular, der giver dig mulighed for at definere et sikkerhedsobjekt
- GSS_Init_sec_context - opretter et klienttoken til at sende til serveren (normalt en udfordring inden for udfordringssvar (godkendelses) -modellen )
- GSS_Accept_sec_context - Håndterer et token oprettet med GSS_Init_sec_context og returnerer eventuelt et svarstoken
- GSS_Wrap - Konverterer applikationsdata til en sikker meddelelsesform (normalt kryptering)
- GSS_Unwrap - udtrækker applikationsdata fra en beskyttet besked (normalt dekryptering)
GSSAPI er blevet standardiseret til C ( RFC 2744 ) og Java ( JSR-072 ).
Begrænsningerne for GSSAPI omfatter, at det kun standardiserer godkendelse , ikke autorisation , og at det antager en klient-server- arkitektur .
For at foregribe fremkomsten af nye sikkerhedsmekanismer inkluderer GSSAPI en særlig pseudo-mekanisme , SPNEGO , som tillader opdagelse og brug af mekanismer, der ikke eksisterede på det tidspunkt, hvor applikationen blev bygget.
Kommunikation med Kerberos
GSSAPI bruges ofte sammen med Kerberos . I modsætning til GSSAPI er Kerberos API ikke standardiseret (og der findes inkompatible API'er). GSSAPI giver dig mulighed for at bruge forskellige implementeringer af Kerberos uden at ændre din applikationskode.
Relaterede teknologier
Grundlæggende GSSAPI-vilkår
- Navn (navn) - en binær streng til at angive en identifikator (brugernavn, applikation osv.) For eksempel bruger Kerberos formatet 'bruger@REALM for brugere og tjeneste/værtsnavn@REALM for applikationer.
- Credential (identitet) - information, der beviser ægtheden af et objekt (normalt en adgangskode eller privat nøgle).
- Kontekst (kontekst) - kommunikationskanalens tilstand
- Token (token) - en uigennemsigtig (til applikationen) besked, der sendes under etableringsfasen af forbindelsen eller under transmissionen af en sikker besked
- Mekanisme - Den underliggende GSSAPI-implementering, der giver det faktiske navn, identitet og tokens. Typiske mekanismer: Kerberos, NTLM , DCE , SESAME , SPKM , LIPKEY .
- Initiativtager/acceptor (initiator/modtager) - den part, der sender det første token, er initiativtageren ; den modsatte side er modtageren . Normalt er modtageren serveren, og initiativtageren er klienten.
Historie
- Juli 1991: IETF CAT (Common Authentication Technology) arbejdsgruppen mødtes i Atlanta under ledelse af John Linn
- September 1993: GSSAPI version 1 offentliggjort ( RFC 1508 , RFC 1509 )
- Maj 1995: SSPI-implementering frigivet med Windows NT 3.51
- Juni 1996: Kerberos-mekanisme til GSSAPI frigivet ( RFC 1964 )
- Januar 1997: GSSAPI version 2 ( RFC 2078 )
- Oktober 1997: SASL-standard offentliggjort, inklusive GSSAPI-mekanisme ( RFC 2222 )
- Januar 2000: Opdatering 1 til GSSAPI version 2 ( RFC 2743 , RFC 2744 )
- August 2004: KITTEN arbejdsgruppemøde (fortsættelse af CAT)
- Maj 2006: Standardiseret brug af GSSAPI til SSH ( RFC 4462 )
Se også
Links