Siden første gang en påloggingsside ble lagt til i et webapplikasjon, har sikkerhet alltid vært en av nøkkelkomponentene som er avgjørende for suksessen til applikasjoner på nettet. Historisk sett ble alt kodet for hånd. Hver webapplikasjon hadde en tilpasset metode for å autentisere og deretter autorisere brukere. Utviklere bygde også inn komponenter for registrering, administrasjon og andre funksjoner som trengs. Selv om det var ganske mye overhead, tillot denne tilnærmingen stor fleksibilitet.
Med adventen av JAAS, Java Authentication and Authorization Service, fikk applikasjoner et sett med grensesnitt og en konfigurasjon de kunne utnytte for å standardisere disse oppgavene. Selv med tillegg av JAAS til spesifikasjonen, har J2EE fortsatt noen problemer å løse før applikasjonsutviklere kan slutte å lage tilpassede APIer. Å velge mellom å bruke J2EE-standardene eller å bygge en tilpasset løsning krever å kjenne til kompromissene for hver og, selvfølgelig, applikasjonens krav.
Denne artikkelen tar sikte på å gi all informasjonen som kreves for å bestemme mellom tilpasset eller containersikkerhet. Jeg diskuterer de vanligste applikasjonssikkerhetsfunksjonene for å gi den nødvendige bakgrunnen for sikkerhet. Etter denne diskusjonen følger en detaljert forklaring av J2EE-sikkerhetsimplementeringene gitt i spesifikasjonene, samt de vanligste metodene for implementering av tilpasset sikkerhet. Etter at du bedre har forstått hver av metodene, bør du ha nok informasjon til å velge hvilken metode som passer best til applikasjonens krav.
Hva er en container?
Før vi diskuterer de forskjellige sikkerhetstypene og sikkerhetsimplementeringsproblemene, la oss se på hva en container er. En container er et miljø der en applikasjon kjører. Det er også synonymt med en J2EE-applikasjonsserver. Når det gjelder J2EE-containere, kjører en J2EE-applikasjon inne i containeren, som har spesifikt ansvar med hensyn til applikasjonen. Det finnes mange forskjellige typer J2EE-containere og forskjellige nivåer av J2EE-støtte. Tomcat fra Apache er en webcontainer som bare implementerer Servlet (webapplikasjon) -delene av J2EE-spesifikasjonen. BEAs WebLogic er en fullt kompatibel J2EE applikasjonsserver, noe som betyr at den støtter alle aspekter av J2EE-spesifikasjonen og har bestått Suns J2EE-sertifiseringstester. Hvis du er usikker på støtten applikasjonsserveren din gir, kan du kontakte leverandøren for mer informasjon.
Søknadssikkerhet
Et annet tema vi må dekke før vi begynner, er skillet mellom applikasjonssikkerhet og andre typer sikkerhet. Søknadssikkerhet er sikkerhet utført direkte av en applikasjon eller indirekte av et rammeverk eller container for en applikasjon med hensyn til brukerne av den applikasjonen. Et eksempel på en applikasjonsbruker er noen som logger på en online bokhandel og kjøper noen få Java-bøker. Det finnes andre typer sikkerhet, for eksempel nettverkssikkerhet og JVM-sikkerhet. Et eksempel på disse sikkerhetstypene er brukeren som starter en Java-prosess på en maskin. Gjennom resten av denne artikkelen, når jeg diskuterer sikkerhet, mener jeg applikasjonssikkerhet. De andre typer sikkerhet strekker seg utenfor diskusjonens omfang.
Fokuset her er spesifikt J2EE-sikkerhet, som er en type applikasjonssikkerhet fordi den omhandler brukere av en J2EE-applikasjon (dvs. innringere). En bruker kan være noen som bruker den elektroniske bokhandelen eller et annet program som bruker bokhandelapplikasjonens innkjøpstjenester, for eksempel en annen online forhandler.
Sikkerhetsfunksjoner til applikasjoner
Det er fem hovedfunksjoner når du vurderer applikasjonssikkerhet: autentisering, autorisasjon, registrering, kontovedlikehold (oppdateringer) og kontosletting / inaktivering. Selv om bare en liten delmengde av alle mulige funksjoner en applikasjon kan ha, er disse de mest grunnleggende og ganske standard for alle applikasjoner. Mindre formelt er disse funksjonene å kjenne brukeren (godkjenning), vite hva brukeren kan gjøre (autorisasjon), opprette nye brukere (registrering), oppdatere brukerinformasjon (kontovedlikehold), og fjerne en bruker eller hindre en bruker i å få tilgang til applikasjonen (kontosletting).
De fleste applikasjoner tillater enten brukeren eller en administrator å utføre disse funksjonene. Når brukere utfører disse funksjonene, gjør de det for seg selv. Administratorer utfører alltid disse funksjonene på vegne av andre brukere.
Som det skal illustreres, kan ikke alle disse funksjonene oppnås uten en tilpasset løsning, selv ikke for autentisering. Vi vil gå kort over hver enkelt for å illustrere konseptene ytterligere og hva J2EE mangler som må spesialbygges.
Godkjenning
Autentisering er prosessen med å identifisere en bruker som interagerer med et program. I skrivende stund kunne J2EE-autentisering implementeres ved hjelp av en rekke løsninger, hver definert som en del av J2EE-spesifikasjonen (versjon 1.0-1.4). Autentisering er hovedkonseptet i denne diskusjonen og vil bli dekket mer detaljert senere. Det er viktig å innse at autentisering er den sikkerhetsfunksjonen som har mest støtte innenfor J2EE-spesifikasjonen, men egendefinert kode eller konfigurasjon er vanligvis nødvendig for å implementere J2EE-autentisering (aka container authentication).
Autorisasjon
Autorisasjon er prosessen med å verifisere at en bruker har tillatelse til å utføre en bestemt handling. J2EE dekker dette emnet, men det er begrenset til rollebasert autorisasjon, noe som betyr at aktiviteten kan begrenses basert på rollene brukeren har fått. For eksempel kan brukere i lederrollen være i stand til å slette beholdning, mens brukere i medarbeiderrollen kanskje ikke gjør det.
I tillegg kan applikasjoner vurdere to forskjellige typer autorisasjoner: Java Runtime Environment (JRE) / container og programautorisasjon. JRE / container-autorisasjon er prosessen for å avgjøre om brukeren som gjør forespørselen har rettigheter til å gjøre det. JRE / beholderen bestemmer dette før kode kjøres. Et eksempel er en J2EE-beholder som først må sjekke om den nåværende brukeren har tillatelse til å utføre en servlet (via en ressurs-URL-begrensning) før servletten kjøres. Denne typen autorisasjon er også kjent som erklærende sikkerhet fordi det er erklært i konfigurasjonsfilene for webapplikasjonen. Med mindre det støttes av containeren, kan ikke den erklærende sikkerheten endres på kjøretid. Deklarativ sikkerhet kan brukes på mange måter for å autorisere J2EE-applikasjonsbrukere, men emnet når utenfor diskusjonens virkeområde. (Se Servlet 2.3 Spesifikasjon kapittel 12. Avsnitt 2 dekker erklærende sikkerhet, og 8 er et godt utgangspunkt for sikkerhetsbegrensninger.)
Som nevnt tidligere, kan brukeren være et annet program eller bare en applikasjonsbruker. Uansett utføres JRE / container-autorisasjon under hver forespørsel. Disse forespørslene kan være HTTP-forespørsler fra en nettleser til et webapplikasjon eller eksterne EJB (Enterprise JavaBeans) -anrop. I begge tilfeller, forutsatt at JRE / containeren kjenner brukeren, kan den utføre autorisasjon basert på brukerens informasjon.
Søknadsgodkjenning er prosessen med å godkjenne når applikasjonen kjøres. Søknadstillatelse kan videre deles inn i rollebasert og segmentbasert autorisasjon. Et eksempel på rollebasert applikasjonsgodkjenning er når en applikasjon bruker forskjellige nivåer av markering basert på om en bruker er en ansatt eller en besøkende (dvs. en ansatt rabatt). J2EE gir API-er kalt programmatisk sikkerhet for å oppnå rollebasert autorisasjon (se Servlet 2.3 Spesifikasjon kapittel 12, avsnitt 3 for mer informasjon).
Segmentbasert autorisasjon er autorisasjon basert på brukerens andre attributter, for eksempel alder eller hobbyer. Segmentbasert autorisasjon kalles slik fordi den grupperer brukere i segmenter basert på spesifikke attributter. J2EE har ingen metode for å implementere segmentbasert autorisasjon. Et eksempel på segmentbasert autorisasjon er om en knapp i et skjema er synlig for brukere over 40 år. Enkelte leverandører kan tilby denne typen autorisasjon, men dette vil garantere at leverandøren låses inn i alle tilfeller.
Registrering
Registrering er prosessen med å legge til en ny bruker i applikasjonen. Applikasjonsbrukere kan kanskje opprette nye kontoer for seg selv, ellers kan applikasjonen velge å begrense denne aktiviteten til applikasjonsadministratorer. J2EE-spesifikasjonen har ikke et API eller en konfigurasjon som lar applikasjoner legge til nye brukere. derfor er denne typen sikkerhet alltid spesialbygd. J2EE mangler muligheten til å fortelle containeren en ny bruker har registrert seg og at informasjonen hennes må opprettholdes og opprettholdes under økten hennes.
Vedlikehold
Kontovedlikehold er prosessen med å endre kontoinformasjon, for eksempel kontaktinformasjon, pålogginger eller passord. De fleste applikasjoner tillater applikasjonsbrukere, så vel som administratorer, å utføre vedlikehold. J2EE-spesifikasjonen mangler også en API eller konfigurasjon for vedlikehold av kontoen. Det mangler en mekanisme for å informere containeren om at brukerinformasjonen er endret.
Sletting
Sletting av konto er vanligvis bare begrenset til administrative brukere. I sjeldne tilfeller kan noen applikasjoner tillate brukere å slette sine egne kontoer. De fleste applikasjoner sletter faktisk aldri brukere; de inaktiverer ganske enkelt kontoen slik at brukeren ikke lenger kan logge på. Å gjøre harde og raske slettinger blir ofte mislikt fordi kontodataene er mye vanskeligere å gjenopplive om nødvendig. J2EE gir ingen måte å fjerne eller inaktivere brukere fra applikasjoner. Det mangler en mekanisme for å fortelle containeren at en bestemt bruker er inaktivert eller fjernet. J2EE mangler også en mekanisme for umiddelbart å logge en bruker ut av applikasjonen når kontoen hennes er slettet.
Hva er containerautentisering?
Containerautentisering er prosessen med å fortelle containeren identiteten til brukeren som gjør den gjeldende forespørselen. For de fleste containere innebærer denne prosessen å knytte strømmen ServletRequest objekt, gjeldende kjøretråd og en intern økt med brukerens identitet. Ved å knytte en økt til identiteten kan beholderen garantere at den gjeldende forespørselen og alle etterfølgende forespørsler fra den samme brukeren kan knyttes til den samme økten, til brukerens økt utløper. Dette øktobjektet er vanligvis ikke det samme som HttpSession objekt, selv om førstnevnte brukes til å lage og vedlikeholde sistnevnte. Hver etterfølgende forespørsel fra samme bruker er tilknyttet økten ved hjelp av enten URL-omskriving eller en økt-informasjonskapsel, i henhold til Servlet 2.3-spesifikasjonen, kapittel 7.
Som nevnt ovenfor i vår diskusjon om autorisasjon, blir alle handlinger som containeren tar så vel som alle handlinger JRE utfører på brukerens vegne nøye sjekket for å sikre at brukeren har tillatelse til å utføre handlingen. For å gjenta vårt forrige eksempel, når containeren kjører en servlet på vegne av brukeren, verifiserer den at brukeren tilhører settet med roller gitt tillatelser til å utføre servleten. JRE 1.4 utfører også disse kontrollene for mange handlinger, inkludert når en fil eller stikkontakt åpnes. JRE-autentisering er et kraftig konsept og kan sikre at enhver forespørsel til en container i det vesentlige er trygg.
For øyeblikket gir J2EE noen få forskjellige mekanismer for implementering av brukerautentisering. Disse inkluderer formbasert autentisering, HTTPS-klientautentisering og grunnleggende HTTP-autentisering. JAAS er inkludert som en påkrevd godkjenningsmetode som containere må støtte. Men spesifikasjonen er ikke streng om hvordan containeren skal gi denne funksjonaliteten; derfor gir hver container forskjellig støtte for JAAS. I tillegg er JAAS i seg selv et frittstående autentiseringsrammeverk og kan brukes til å implementere containerautentisering uansett om spesifikasjonen støtter det. Jeg forklarer dette konseptet mer detaljert senere.
Hver av autentiseringsmekanismene gir en standard måte å gi containeren informasjon om brukeren. Jeg refererer til dette som legitimasjon realisering. Beholderen må fremdeles bruke denne informasjonen for å bekrefte at brukeren eksisterer og har tillatelser som er tilstrekkelige til å gjøre forespørselen. Jeg refererer til det som godkjenning av legitimasjon. Noen containere gir konfigurasjon for å sette opp autentiseringsautentisering, og andre gir grensesnitt som må implementeres.
J2EE autentiseringsmetoder
La oss se kort på noen av de vanligste metodene for implementering og konfigurering av containerautentisering.
Skjemabasert autentisering
Formbasert autentisering lar brukerne identifiseres og autentiseres med J2EE-applikasjonsserveren ved hjelp av hvilket som helst HTML-skjema. Skjemahandlingen må være j_security_check og to HTTP-forespørselsparametere (skjemainputfelt) må alltid være i forespørselen, den ene kalles j_username og den andre, j_passord. Ved å bruke skjemabasert autentisering, skjer legitimasjon når skjemaet sendes inn og brukernavn og passord blir sendt til serveren.
Her er et eksempel på en JSP-side (JavaServer Pages) som bruker formbasert godkjenning:
Logg inn Skriv inn brukernavnet ditt:Skriv inn passordet ditt:
