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 Sikkerhetssjef
s, 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 LoginModule
s, 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:
- Lage en
InnloggingContext
- Valgfritt passere en
CallbackHandler
tilInnloggingContext
, for innsamling eller behandling av autentiseringsdata - Utfør autentisering ved å ringe
InnloggingContext
sLogg Inn()
metode - 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:
- Under initialiseringen,
InnloggingContext
finner konfigurasjonsoppføringen"Mitt eksempel"
i en JAAS-konfigurasjonsfil (som du konfigurerte) for å bestemme hvilkenLoginModule
s for å laste inn (se figur 2) - Under pålogging vil
InnloggingContext
ringer hverLoginModule
sLogg Inn()
metode - Hver
Logg Inn()
metoden utfører autentisering eller verver enCallbackHandler
- De
CallbackHandler
bruker en eller flereRing tilbake
s for å samhandle med brukeren og samle innspill - En ny
Emne
forekomst er fylt med autentiseringsdetaljer somRektor
s 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
Felles | Emne , Rektor , legitimasjon (legitimasjon er ikke noen spesifikk klasse, men kan være et hvilket som helst objekt) |
Godkjenning | InnloggingContext , LoginModule , CallbackHandler , Ring tilbake |
Autorisasjon | Politikk , 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
Rektor
s - Offentlig legitimasjon: Slik som navn eller offentlige nøkler
- Privat legitimasjon: Som passord eller private nøkler
Rektor
s representerer Emne
identiteter. De implementerer java.sikkerhet. rektor
grensesnitt (som går før JAAS) og java.io Serialiserbar
. EN Emne
viktigste metode er getName ()
, som returnerer en identitets strengnavn. Siden a Emne
forekomst inneholder en rekke Rektor
s, 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 Sett
s 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 Emne
s. 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 LoginModule
s å 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 LoginModule er 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 Rektor s 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
JndiLoginModule | Verifiserer mot en katalogtjeneste konfigurert under JNDI (Java Naming and Directory Interface) |
Krb5LoginModule | Autentiserer ved hjelp av Kerberos-protokoller |
NTLoginModule | Bruker den nåværende brukerens NT-sikkerhetsinformasjon for å autentisere |
UnixLoginModule | Bruker 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. |
| Utfører godkjenningen. |
begå() | Kalt av InnloggingContext etter at den har godtatt resultatene fra alle LoginModule er definert for denne applikasjonen. Vi tildeler Rektor s 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 Rektor s eller legitimasjon er tilordnet til Emne . |
Logg ut() | Fjerner Rektor s 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
CallbackHandler
s og Ring tilbake
s 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).