Programmering

Alt det JAAS

Har du noen gang trengt å opprette en påloggingsautentiseringsmekanisme for et program? Oddsen er, du har, og sannsynligvis mer enn en gang, med hver nye implementering som er nær, men ikke identisk, med den forrige. For eksempel kan en implementering bruke en Oracle-database, en annen kan bruke en NT-godkjenning, og en annen, en LDAP-katalog (lightweight access directory protocol). Ville det ikke vært fint å støtte alle disse sikkerhetsmekanismene uten å endre noen applikasjonsnivå-kode?

Nå i Java-verdenen kan du med Java Authentication and Authorization Service (JAAS). Denne relativt nye API-en var en utvidelse i J2SE (Java 2 Platform, Standard Edition) 1.3, er en kjerne-API i J2SE 1.4, og er også en del av J2EE (Java 2 Platform, Enterprise Edition) 1.3-spesifikasjonen. I denne artikkelen lærer vi deg JAAS-grunnleggende og viser deg hvordan du effektivt kan bruke JAAS på virkelige applikasjoner. Vi baserte applikasjonen til denne artikkelen på egne erfaringer med å integrere JAAS i et eksisterende Java-webbasert system som brukte et RDBMS (relasjonsdatabasehåndteringssystem) for lagring av brukerinnloggingsinformasjon. Med JAAS designet vi mer robuste, fleksible og konsekvente påloggings- og autentiseringsmekanismer.

Du kan laste ned et komplett sett med arbeidseksempler fra Resources nedenfor (inkluderer Java-kilder, JSPer (JavaServer Pages), JAAS-konfigurasjon, med database og build-skript). Vi testet disse eksemplene ved hjelp av Resin-serveren med JDBC (Java Database Connectivity) og MySQL-databasen.

Java Authentication and Authorization: Det store bildet

Før JAAS ble Javas sikkerhetsmodell for det meste formet av opprinnelsen som et plattformuavhengig språk for distribuerte, nettverksapplikasjoner. I sine tidlige dager dukket Java ofte opp som mobilkode, for eksempel nettleserbaserte applets, og derfor fokuserte den første sikkerhetsmodellen på å beskytte brukere basert på hvor koden oppsto og som skapte den. Tidlige Java-sikkerhetsmekanismer som Sikkerhetssjefs, sandkassekonseptet, kodesignering og policy-filer var alle ment for å beskytte brukere mot systemet.

Oppfinnelsen av JAAS gjenspeiler Java's utvikling til et generelt programmeringsspråk, brukt til å implementere tradisjonelle klient- og serverapplikasjoner som krever pålogging og tilgangskontroll. JAAS beskytter systemet mot brukere ved å tillate eller nekte tilgang basert på hvem eller hva som driver programmet. Mens JAAS kan utføre både autentisering og autorisasjon, fokuserer vi i denne artikkelen primært på autentisering.

JAAS kan forenkle Java-sikkerhetsutviklingen din ved å legge et abstraksjonslag mellom applikasjonen og ulike underliggende autentiserings- og autorisasjonsmekanismer. Denne uavhengigheten fra plattformer og algoritmer lar deg bruke forskjellige sikkerhetsmekanismer uten å endre koden på applikasjonsnivå. Som med de fleste Java-sikkerhets-API-er, oppnår JAAS denne implementeringsuavhengigheten gjennom et utvidbart rammeverk av pluggbare tjenesteleverandørgrensesnitt (SPI): et sett med abstrakte klasser og grensesnitt som spesifikke implementeringer er utviklet for.

Figur 1 nedenfor gir en oversikt på høyt nivå av hvordan JAAS oppnår denne pluggbarheten. Søknadslagskoden din handler primært om a InnloggingContext. Under det InnloggingContext er et sett med en eller flere dynamisk konfigurerte LoginModules, som håndterer den faktiske autentiseringen ved hjelp av riktig sikkerhetsinfrastruktur.

JAAS gir noen referanser LoginModule implementeringer, for eksempel JndiLoginModule; Du kan også utvikle dine egne, slik vi gjør her med RdbmsLoginModule. Vi viser også hvordan du raskt kan sette opp en applikasjon med et utvalg av implementeringer ved hjelp av en enkel konfigurasjonsfil.

I tillegg til å være pluggbar, kan JAAS stables: i sammenheng med en enkelt pålogging kan et sett med sikkerhetsmoduler stables oppå hverandre, hver som kalles i rekkefølge og hver samhandler med en annen sikkerhetsinfrastruktur.

JAAS-aspekter er modellert på noen kjente sikkerhetsarkitekturmønstre og eksisterende rammer. Den stabile funksjonen, for eksempel, ligner bevisst rammen Unix Pluggable Authentication Module (PAM). Fra et transaksjonsmessig synspunkt, vedtar JAAS atferd som ligner tofasetaktsprotokoller (2PC). JAASs sikkerhetskonfigurasjonskonsepter, inkludert Politikk filer og Tillatelser, kommer fra J2SE 1.2 sikkerhetspakker. JAAS låner også ideer fra andre etablerte sikkerhetsrammer, for eksempel X.509-sertifikater, som navnet kommer fra Emne er avledet (du vil lære mer om Emne seinere).

Merk: JAAS er bare en av flere nye Java-sikkerhets-APIer. For mer informasjon om Java-sikkerhet, se sidefeltet "The Java Security Puzzle" og Resources nedenfor.

JAAS på klient- og serversiden

Du kan bruke JAAS på både klienten og serveren. Å bruke den på klientsiden er grei, som vi snart vil demonstrere. På serversiden blir ting litt mer komplekse. For tiden er JAAS i applikasjonsservermarkedet litt inkonsekvent; J2EE app-servere bruker JAAS litt annerledes, avhengig av hvilken du bruker. For eksempel integrerer JBossSX JAAS pent i sin generelle sikkerhetsramme (som er detaljert i Scott Starks gode JavaWorld artikkel "Integrer sikkerhetsinfrastrukturer med JBossSX" (august 2001)). Imidlertid, selv om WebLogic 6.x støtter JAAS, varierer detaljene.

Så du kan forstå JAAS fra både server- og klientsiden, vil vi demonstrere eksempler på begge deler i denne artikkelen. Og for enkelhets skyld på serveren, bruker vi Resin-applikasjonsserveren, slik at vi kan starte med et renere skifer (Resin har et pluggbart autentiseringsskjema, men det er ikke standard, så bruk av JAAS gir oss mer bærbarhet alternativene senere).

Kjernen JAAS

For å komme i gang med JAAS, må du først sørge for at den er installert. J2SE 1.4 inkluderer allerede JAAS; J2SE 1.3 gjør det ikke. Hvis du vil fortsette å bruke J2SE 1.3, laster du ned JAAS fra Sun Microsystems. Når du har lastet ned og installert JAAS i en gitt katalog, vil du se en underkatalog kalt lib, som inneholder en fil med navnet jaas.jar. Du må legge til denne filen på klassestien eller kopiere den til JRE-utvidelseskatalogen (Java Runtime Environment) (i \ lib \ ekst, hvor er din JRE-adresse). Du er da JAAS-klar. Merk: Hvis du bruker en applikasjonsserver, kan den allerede inneholde JAAS. Sjekk serverens dokumentasjon for detaljer.

Vær oppmerksom på at du kan endre noen av de JAAS-relaterte systemegenskapsinnstillingene (så vel som mange andre Java-sikkerhetsinnstillinger) i Java-sikkerhetsegenskapsfilen. Denne filen, java.sikkerhet, ligger i / lib / sikkerhet katalog og skrevet i standard Java-formatfilformat.

Å bruke JAAS-autentisering fra applikasjonen din innebærer vanligvis følgende trinn:

  1. Lage en InnloggingContext
  2. Valgfritt passere en CallbackHandler til InnloggingContext, for innsamling eller behandling av autentiseringsdata
  3. Utfør autentisering ved å ringe InnloggingContexts Logg Inn() metode
  4. Utfør privilegerte handlinger ved hjelp av den returnerte Emne (forutsatt at innlogging lykkes)

Her er et minimalt eksempel:

 LoginContext lc = new LoginContext ("MyExample"); prøv {lc.login (); } fangst (LoginException) {// Autentisering mislyktes. } // Godkjenning er vellykket, vi kan nå fortsette. // Vi kan bruke det returnerte emnet hvis vi vil. Emne sub = lc.getSubject (); Subject.doAs (sub, new MyPrivilegedAction ()); 

Under dekslene skjer det noen få andre ting:

  1. Under initialiseringen, InnloggingContext finner konfigurasjonsoppføringen "Mitt eksempel" i en JAAS-konfigurasjonsfil (som du konfigurerte) for å bestemme hvilken LoginModules for å laste inn (se figur 2)
  2. Under pålogging vil InnloggingContext ringer hver LoginModules Logg Inn() metode
  3. Hver Logg Inn() metoden utfører autentisering eller verver en CallbackHandler
  4. De CallbackHandler bruker en eller flere Ring tilbakes for å samhandle med brukeren og samle innspill
  5. En ny Emne forekomst er fylt med autentiseringsdetaljer som Rektors og legitimasjon

Vi forklarer ytterligere detaljer nedenfor, men la oss se på de viktigste JAAS-klassene og grensesnittene som er involvert i prosessen. Disse er vanligvis delt inn i følgende tre grupper:

Tabell 1. JAAS-klasser og grensesnitt

FellesEmne, Rektor, legitimasjon (legitimasjon er ikke noen spesifikk klasse, men kan være et hvilket som helst objekt)
GodkjenningInnloggingContext, LoginModule, CallbackHandler, Ring tilbake
AutorisasjonPolitikk, AuthPermission, PrivateCredentialPermission

De fleste av disse klassene og grensesnittene er i javax.security.auth pakkens underpakker, med noen forhåndsbygde implementeringer i com.sun.security.auth pakke, inkludert bare i J2SE 1.4.

Merk: Fordi vi fokuserer på autentisering i denne artikkelen, dykker vi ikke ned i autorisasjonsklassene.

Vanlige: Emner, rektorer og legitimasjon

De Emne klasse representerer en godkjent enhet: en sluttbruker eller administrator, eller en webtjeneste, enhet eller annen prosess. Klassen inneholder tre sett med sikkerhetsinformasjonstyper:

  • Identiteter: I form av en eller flere Rektors
  • Offentlig legitimasjon: Slik som navn eller offentlige nøkler
  • Privat legitimasjon: Som passord eller private nøkler

Rektors representerer Emne identiteter. De implementerer java.sikkerhet. rektor grensesnitt (som går før JAAS) og java.io Serialiserbar. EN Emneviktigste metode er getName (), som returnerer en identitets strengnavn. Siden a Emne forekomst inneholder en rekke Rektors, det kan dermed ha flere navn. Fordi et personnummer, påloggings-ID, e-postadresse og så videre, alle kan representere en bruker, viser flere identiteter seg å være vanlige i den virkelige verden.

Det siste elementet her, legitimasjon, er ikke en klasse eller et grensesnitt, men kan være et hvilket som helst objekt. Legitimasjonsinformasjon kan inkludere enhver autentiseringsgjenstand, for eksempel en billett, nøkkel eller passord, som spesifikke sikkerhetssystemer kan kreve. De Emne klassen holder unik Setts med privat og offentlig legitimasjon, som kan hentes med metoder som getPrivateCredentials () og getPublicCrendentials (). Disse metodene brukes oftere av sikkerhetsundersystemer enn i applikasjonslaget.

Autentisering: LoginContext

Søknadslaget ditt bruker InnloggingContext som sin primære klasse for autentisering Emnes. InnloggingContext representerer også hvor JAAS dynamiske pluggbarhet spiller inn, for når du konstruerer en InnloggingContext, angir du en navngitt konfigurasjon som skal lastes inn. De InnloggingContext laster vanligvis konfigurasjonsinformasjonen fra en tekstfil, som igjen forteller InnloggingContext hvilken LoginModules å bruke under pålogging.

De tre vanlige metodene i InnloggingContext er:

Tabell 2. LoginContext-metoder

Logg Inn()Utfører pålogging, et relativt komplekst trinn som påkaller alle LoginModuleer spesifisert for denne konfigurasjonen. Hvis det lykkes, oppretter det en godkjent Emne. Hvis det mislykkes, kaster det a Logg på unntak.
getSubject ()Returnerer det autentiserte Emne.
Logg ut()Logger ut det autentiserte Emne og fjerner sin Rektors og legitimasjon.

Vi vil vise hvordan du bruker disse metodene senere.

Autentisering: LoginModule

LoginModule er grensesnittet til spesifikke autentiseringsmekanismer. J2SE 1.4 leveres med et sett klar til bruk LoginModules, gjelder også:

Tabell 3. LoginModules i J2SE 1.4

JndiLoginModuleVerifiserer mot en katalogtjeneste konfigurert under JNDI (Java Naming and Directory Interface)
Krb5LoginModuleAutentiserer ved hjelp av Kerberos-protokoller
NTLoginModuleBruker den nåværende brukerens NT-sikkerhetsinformasjon for å autentisere
UnixLoginModuleBruker den nåværende brukerens Unix-sikkerhetsinformasjon for å autentisere

Sammen med disse modulene kommer et sett med tilsvarende betong Rektor implementeringer i com.sun.security.auth pakke, for eksempel NTDomainRektor og UnixPrincipal.

De LoginModule grensesnittet har fem metoder:

Tabell 4. LoginModule-metoder

initialisere ()Kalt etter LoginModule er konstruert.
Logg Inn()Utfører godkjenningen.
begå()Kalt av InnloggingContext etter at den har godtatt resultatene fra alle LoginModuleer definert for denne applikasjonen. Vi tildeler Rektors og legitimasjon til Emne her.
avbryte()Kalt når noen LoginModule for denne applikasjonen mislykkes (selv om tidligere i rekkefølge kan ha lykkes - slik som en 2PC-modell). Nei Rektors eller legitimasjon er tilordnet til Emne.
Logg ut()Fjerner Rektors og legitimasjon knyttet til Emne.

Applikasjonslaget kaller ingen av disse metodene direkte - InnloggingContext påkaller dem etter behov. Eksemplet vårt nedenfor vil utdype implementeringene av disse metodene.

Autentisering: CallbackHandlers og Callbacks

CallbackHandlers og Ring tilbakes la en LoginModule samle nødvendig autentiseringsinformasjon fra en bruker eller et system, mens du forblir uavhengig av selve interaksjonsmekanismen. Vi vil utnytte den muligheten i vårt design - vårt RdbmsLoginModule avhenger ikke av hvordan brukerlegitimasjonen (brukernavn / passord) oppnås, og kan dermed brukes i de forskjellige applikasjonsmiljøene vi vil illustrere (enten fra kommandolinjen eller fra en JSP).

$config[zx-auto] not found$config[zx-overlay] not found