Siden første gang en login-side blev føjet til en webapplikation, har sikkerhed altid været en af nøglekomponenterne, der er afgørende for succesen med applikationer på Internettet. Historisk set blev alt kodet i hånden. Hver webapplikation havde en tilpasset metode til godkendelse og derefter godkendelse af brugere. Udviklere byggede også komponenter til registrering, administration og enhver anden nødvendig funktion. Selvom en hel del overhead tillod denne tilgang stor fleksibilitet.
Med fremkomsten af JAAS, Java Authentication and Authorization Service, fik applikationer et sæt grænseflader og en konfiguration, de kunne udnytte til at standardisere disse opgaver. Selv med tilføjelsen af JAAS til specifikationen har J2EE stadig et par problemer at løse, før applikationsudviklere kan stoppe med at oprette brugerdefinerede API'er. At vælge mellem at bruge J2EE-standarderne eller opbygge en brugerdefineret løsning kræver at kende kompromiserne for hver enkelt og selvfølgelig din applikations krav.
Denne artikel sigter mod at give alle de nødvendige oplysninger til at vælge mellem brugerdefineret eller containersikkerhed. Jeg diskuterer de mest almindelige applikationssikkerhedsfunktioner for at give den nødvendige baggrund for sikkerhed. Efter denne diskussion følger en detaljeret forklaring af J2EE-sikkerhedsimplementeringerne i specifikationerne samt de mest almindelige metoder til implementering af brugerdefineret sikkerhed. Når du bedre har forstået hver af metoderne, skal du have tilstrækkelig information til at vælge, hvilken metode der bedst passer til din applikations krav.
Hvad er en container?
Inden vi diskuterer de forskellige sikkerhedstyper og sikkerhedsimplementeringsproblemer, lad os gennemgå hvad en beholder er. En container er et miljø, hvor en applikation kører. Det er også synonymt med en J2EE-applikationsserver. Med hensyn til J2EE-containere kører en J2EE-applikation inde i containeren, som har specifikt ansvar med hensyn til applikationen. Der er mange forskellige typer J2EE-containere og forskellige niveauer af J2EE-support. Tomcat fra Apache er en webcontainer, der kun implementerer Servlet (webapplikation) dele af J2EE-specifikationen. BEAs WebLogic er en fuldt kompatibel J2EE-applikationsserver, hvilket betyder at den understøtter alle aspekter af J2EE-specifikationen og har bestået Suns J2EE-certificeringstest. Hvis du er usikker på den support, din applikationsserver yder, skal du kontakte sælgeren for at få flere oplysninger.
Applikationssikkerhed
Et andet emne, vi skal dække, inden vi begynder, er sondringen mellem applikationssikkerhed og andre typer sikkerhed. Applikationssikkerhed er sikkerhed udført direkte af en applikation eller indirekte af en ramme eller container til en applikation i forhold til applikationens brugere. Et eksempel på en applikationsbruger er en person, der logger ind i en online boghandel og køber et par Java-bøger. Der findes andre typer sikkerhed, såsom netværkssikkerhed og JVM-sikkerhed. Et eksempel på disse sikkerhedstyper er den bruger, der starter en Java-proces på en maskine. I resten af dette papir, når jeg diskuterer sikkerhed, mener jeg applikationssikkerhed. De andre typer sikkerhed rækker uden for denne diskussions rækkevidde.
Fokus her er specifikt J2EE-sikkerhed, som er en type applikationssikkerhed, fordi den beskæftiger sig med en J2EE-applikations brugere (dvs. opkaldere). En bruger kan være en person, der bruger online-boghandlen eller en anden applikation, der bruger boghandel-applikationens indkøbstjenester, såsom en anden online-forhandler.
Sikkerhedsfunktioner i applikationer
Der er fem hovedfunktioner, når man overvejer applikationssikkerhed: godkendelse, godkendelse, registrering, kontovedligeholdelse (opdateringer) og kontosletning / inaktivering. Selvom kun en lille delmængde af alle de mulige funktioner, en applikation kan have, er disse de mest grundlæggende og ret standard for alle applikationer. Mindre formelt kender disse funktioner brugeren (godkendelse), ved hvad brugeren kan gøre (autorisation), opretter nye brugere (registrering), opdaterer brugerinformation (kontovedligeholdelse) og fjerner en bruger eller forhindrer en bruger i at få adgang til applikationen (kontosletning).
De fleste applikationer tillader enten brugeren eller en administrator at udføre disse funktioner. Når brugere udfører disse funktioner, gør de det for sig selv. Administratorer udfører altid disse funktioner på vegne af andre brugere.
Som det vil blive illustreret, kan alle disse funktioner ikke udføres uden en brugerdefineret løsning, selv til godkendelse. Vi vil kort gennemgå hver enkelt for yderligere at illustrere begreberne, og hvad J2EE mangler, der skal skræddersyes.
Godkendelse
Godkendelse er processen med at identificere en bruger, der interagerer med en applikation. På dette tidspunkt kunne J2EE-godkendelse implementeres ved hjælp af en række løsninger, hver defineret som en del af J2EE-specifikationen (version 1.0-1.4). Godkendelse er hovedbegrebet i denne diskussion og vil blive behandlet mere detaljeret senere. Det er vigtigt at indse, at godkendelse er den sikkerhedsfunktion, der har mest support inden for J2EE-specifikationen, men brugerdefineret kode eller konfiguration er normalt påkrævet for at implementere J2EE-godkendelse (også kaldet containergodkendelse).
Bemyndigelse
Autorisation er processen med at kontrollere, at en bruger har tilladelse til at udføre en bestemt handling. J2EE dækker dette emne, men det er begrænset til rollebaseret autorisation, hvilket betyder, at aktivitet kan begrænses ud fra de roller, brugeren har fået. For eksempel kan brugere i lederrollen muligvis slette beholdning, mens brugere i medarbejderrollen muligvis ikke.
Derudover kan applikationer overveje to forskellige typer godkendelser: Java Runtime Environment (JRE) / container og applikationsgodkendelse. JRE / containertilladelse er processen til at bestemme, om den bruger, der fremsætter anmodningen, har privilegier til at gøre det. JRE / beholderen bestemmer dette inden kodeudførelse. Et eksempel er en J2EE-container, der først skal kontrollere, om den aktuelle bruger har tilladelse til at udføre en servlet (via en ressource-URL-begrænsning), før servetten udføres. Denne type godkendelse kaldes også erklærende sikkerhed fordi det er deklareret i konfigurationsfilerne til webapplikationen. Medmindre det understøttes af containeren, kan den erklærende sikkerhed ikke ændres under kørsel. Deklarativ sikkerhed kan bruges på mange måder til at autorisere J2EE-applikationsbrugere, men dette emne når uden for denne diskussions rækkevidde. (Se Servlet 2.3 Specifikation kapitel 12. Afsnit 2 dækker erklærende sikkerhed, og 8 er et godt udgangspunkt for sikkerhedsbegrænsninger.)
Som nævnt før kan brugeren være en anden applikation eller simpelthen en applikationsbruger. Uanset hvad udføres JRE / containertilladelse under hver anmodning. Disse anmodninger kan være HTTP-anmodninger fra en browser til en webapplikation eller eksterne EJB-opkald (Enterprise JavaBeans). I begge tilfælde forudsat at JRE / containeren kender brugeren, kan den udføre autorisation baseret på brugerens oplysninger.
Ansøgningstilladelse er godkendelsesprocessen, når applikationen udføres. Ansøgningstilladelse kan yderligere opdeles i rollebaseret og segmentbaseret godkendelse. Et eksempel på rollebaseret applikationsgodkendelse er, når en applikation anvender forskellige markeringsniveauer baseret på, om en bruger er en medarbejder eller en besøgende (dvs. en medarbejderrabat). J2EE leverer kaldte API'er programmatisk sikkerhed for at udføre rollebaseret autorisation (se Servlet 2.3 Specifikation kapitel 12, afsnit 3 for mere information).
Segmentbaseret autorisation er autorisation baseret på en brugers andre attributter, såsom alder eller hobbyer. Segmentbaseret autorisation kaldes sådan, fordi den grupperer brugere i segmenter baseret på specifikke attributter. J2EE har ingen metode til implementering af segmentbaseret autorisation. Et eksempel på segmentbaseret autorisation er, om en knap på en formular er synlig for brugere over 40 år. Visse leverandører tilbyder muligvis denne type godkendelse, men dette vil garantere, at leverandøren låses fast i alle tilfælde.
Registrering
Registrering er processen med at tilføje en ny bruger til applikationen. Applikationsbrugere kan muligvis oprette nye konti til sig selv, ellers kan applikationen vælge at begrænse denne aktivitet til applikationsadministratorer. J2EE-specifikationen har ikke en API eller konfiguration, der gør det muligt for applikationer at tilføje nye brugere; derfor er denne type sikkerhed altid specialbygget. J2EE mangler evnen til at fortælle containeren, som en ny bruger har registreret, og at hendes oplysninger skal vedholdes og vedligeholdes under hendes session.
Vedligeholdelse
Kontovedligeholdelse er processen med at ændre kontooplysninger, såsom kontaktoplysninger, login eller adgangskoder. De fleste applikationer tillader applikationsbrugere såvel som administratorer at udføre vedligeholdelse. J2EE-specifikationen mangler også en API eller konfiguration til kontovedligeholdelse. Der mangler en mekanisme til at informere containeren om, at brugeroplysninger er ændret.
Sletning
Sletning af konto er normalt kun begrænset til administrative brugere. I sjældne tilfælde kan nogle applikationer tillade brugere at slette deres egne konti. De fleste applikationer sletter faktisk aldrig brugere; de inaktiverer simpelthen kontoen, så brugeren ikke længere kan logge på. At udføre hårde og hurtige sletninger er normalt forkert, fordi kontodataene er meget sværere at genoplive, hvis det er nødvendigt. J2EE giver ingen måde at fjerne eller inaktivere brugere fra applikationer. Det mangler en mekanisme til at fortælle containeren, at en bestemt bruger er blevet inaktiveret eller fjernet. J2EE mangler også en mekanisme til straks at logge en bruger ud af applikationen, når hendes konto er blevet slettet.
Hvad er containergodkendelse?
Containergodkendelse er processen med at fortælle containeren identiteten på den bruger, der fremsætter den aktuelle anmodning. For de fleste containere involverer denne proces tilknytning af strømmen ServletForespørgsel objekt, den aktuelle udførelsestråd og en intern session med brugerens identitet. Ved at knytte en session til identiteten kan containeren garantere, at den aktuelle anmodning og alle efterfølgende anmodninger fra den samme bruger kan tilknyttes den samme session, indtil brugerens session udløber. Dette sessionsobjekt er normalt ikke det samme som HttpSession objekt, selvom førstnævnte bruges til at skabe og vedligeholde sidstnævnte. Hver efterfølgende anmodning fra den samme bruger tilknyttes sessionen ved hjælp af enten URL-omskrivning eller en session-cookie i henhold til Servlet 2.3-specifikationen, kapitel 7.
Som nævnt ovenfor i vores diskussion af autorisation kontrolleres hver handling, som containeren udfører, samt enhver handling, som JRE foretager på brugerens vegne, omhyggeligt for at sikre, at brugeren har tilladelse til at udføre handlingen. For at gentage vores tidligere eksempel, når containeren udfører en servlet på brugerens vegne, verificerer den, at brugeren tilhører det sæt roller, der gives tilladelser til at udføre denne servlet. JRE 1.4 udfører også disse kontroller for mange handlinger, herunder når en fil eller et stik åbnes. JRE-godkendelse er et stærkt koncept og kan sikre, at enhver anmodning til en container i det væsentlige er sikker.
I øjeblikket leverer J2EE et par forskellige mekanismer til implementering af brugergodkendelse. Disse inkluderer formbaseret godkendelse, HTTPS-klientgodkendelse og HTTP-grundlæggende godkendelse. JAAS er inkluderet som en krævet godkendelsesmetode, som containere skal understøtte. Men specifikationen er ikke streng med hensyn til, hvordan containeren skal levere denne funktionalitet; derfor giver hver container forskellige support til JAAS. Derudover er JAAS i sig selv en selvstændig godkendelsesramme og kan bruges til at implementere containergodkendelse uanset om specifikationen understøtter den. Jeg forklarer dette koncept mere detaljeret senere.
Hver af godkendelsesmekanismerne giver en standard måde at give containeren information om brugeren. Jeg henviser til dette som legitimationsopfyldelse. Containeren skal stadig bruge disse oplysninger til at bekræfte, at brugeren findes og har tilladelser, der er tilstrækkelige til at fremsætte anmodningen. Jeg henviser til det som godkendelsesgodkendelse. Nogle containere giver konfiguration til at oprette godkendelsesgodkendelse, og andre giver grænseflader, der skal implementeres.
J2EE-godkendelsesmetoder
Lad os se kort på nogle af de mest almindelige metoder til implementering og konfiguration af containergodkendelse.
Formbaseret godkendelse
Formbaseret godkendelse gør det muligt for brugere at blive identificeret og godkendt med J2EE-applikationsserveren ved hjælp af en hvilken som helst HTML-formular. Formularhandlingen skal være j_sikkerhed_check og to HTTP-anmodningsparametre (formularinputfelter) skal altid være i anmodningen, den ene kaldes j_username og den anden, j_password. Ved hjælp af formbaseret godkendelse opstår legitimationsrealisering, når formularen sendes, og brugernavnet og adgangskoden sendes til serveren.
Her er et eksempel på en JSP-side (JavaServer Pages), der bruger formbaseret godkendelse:
Login Indtast dit brugernavn:Skriv dit kodeord:
