Tải bản đầy đủ - 0 (trang)
Chapter 29. J2EE Security in WebSphere

Chapter 29. J2EE Security in WebSphere

Tải bản đầy đủ - 0trang

thisamootpoint.TheproblemisthattoolslikeWSADUTCuse

introspectiontodetermineavailableEJBmethodsignaturesand

names,andfromthereprovideaplatformtoexecutethesemethods.

AnyonewithacopyofWebSphereStudiocanusetheUTCtoquery

anunsecuredapplicationserverdirectlyandpossiblyobtain

confidentialdatabycasuallybrowsingtheEJBsthatareavailable.

Ourrecommendationisthatinnearlyeveryapplication,beitforan

intranetortheInternet,ataminimumthatyouturnonWebSphereJ2EE

securityandusetheJ2EEsecuritymodel.Thiswillbegintoplugsomeof

theholesinyoursecurityinfrastructure.Inthenextsectionswe'll

examinethebasicpartsofJ2EEsecurity,andseehowWebSphere

implementsthem.Finally,we'lltakealookattheedgesofdealingwith

securityinWebSpherehandlingsomeofthemoreinteresting

programmaticissuesthatusingJ2EEsecuritycanbringup.Wewon't

covermostofthehardissuesofdevelopingatrulysecureproduction

environment;thingslikefirewallplacement,serverhardening,and

physicalsecurityarebeyondthescopeofthisbook.However,wewillat

leastintroduceyoutobasicthingsyoucandoforyourownapplications

thatwillhelpyoubegintocreateamoresecureenvironment.



29.1J2EESecurityOverview

WhatdoesJ2EEsecurity,consistof?Forthemostpartitboilsdownto

answeringbasicquestionsaboutyoursystem:

Whoisaskingforthisparticularrequest?Thisistheproblemof

authentication.Youdon'tnecessarilywantanyoneoffthestreetto

accessyourapplication;insteadyouwanttoknowexactlywho

makeseachrequest,andyouwanttomakesurethattheyarewho

theysaytheyare.

Shouldthepersonorprogrammakingthisrequestbeallowedto

makethisrequest?Thisistheproblemofauthorization.

Howdoyouknowthatauser'sinteractionswithanapplicationare

privateandnotviewedbyotherpersons?Howdoyouknowthat

requestsandresponseshaven'tbeenalteredinmid-flight?These

areissuesofprivacy(oftendealtwiththroughencryption)and

integrity(thedomainofchecksumsanddigitalsignatures).

Atitscore,youhavetodeterminehowmuchriskyouarewillingtotake

foryourapplication.Aswe'vesaidearlier,implementingnosecurity

entailsverylittleeffortbutcomeswithaveryhighrisk.Ontheotherhand,

lockingdowneverythingcanrequireaveryhighlevelofeffort,butcarries

withitarelativelylowrisk.Inthenextsection,we'llexaminehowthese

issuesareaddressedinWebSphere.



29.1.1J2EESecurityArchitecture

Figure29.1showssometypicalJ2EE-definedpathsintoaWAS.Using

thisdiagramasaguide,we'llquicklyaddresswhereeachoftheareas

identifiedintheprevioussectioncomeintoplayinWebSphere.



Figure29.1.SecuredpathsinWebSphere.



Thefirstpathwe'llexamineisthemostcommontheoneintotheWeb

containerfromaWebbrowser(AinFigure29.1).Onthispath,allthree

areasofconcernmaycomeintoplay.First,youwillwanttomakethe

conversationprivate;thewaythisisdoneisthroughtheuseofHTTPS

(theversionofHTTPthatrunsovertheSSL).ConfiguringHTTPSfor

yourWebserver,applicationserver,andtheWebSphereWebServer

plug-inisbeyondthescopeofthisbook,butiscoveredintheInfoCenter.

Ofmoreimmediateconcerntoyouhereishowyouidentifyyouruserto

theWebcontainerandhowyoudeterminewhetherornotthatusercan

accessthatparticularserver.



29.1.2J2EEAuthenticationintheWebContainer

SecureinteractionwithaWebcontainerinitiatesachallenge-response

interactionwheretheWebserverchallengestheclienttoprovideproper

authenticationbeforeitwillhonortherequest.Authenticationconsistsof

twoprocesses:identificationandvalidation.Identificationmeansthata



partymakingarequesthastoprovidesomeproofofidentity,calleda

credential.ThisisoftenintheformofauserIDandpasswordpair

(somethingthatonlythatpersonwouldknow)oracertificate(something

onlythatpersonshouldpossess).Validationconsistsofonepartner

presentinghiscredentials,withtheotherpartnerinthetransaction

validatingthem.

Theservletspecificationoutlinesfourmethodsforprovidingcredentials

toaWebcontainer:

HTTPBasicAuthenticationThismethodisthemost

straightforward.ThisusesasetofheadersdefinedintheHTTP

specification(theHTTPbasic-authenticationheaders)andpassesa

userIDandpasswordtothecontainerinthisheaderinresponseto

thechallenge.WhenaWebbrowserfirstattemptstoaccessapage

thatissetupforbasicauthentication,theWebserverandthe

browsercoordinatewitheachotheraccordingtoaflowsetforthin

theHTTPspecification.Theserverissuesa"challenge"tothe

browser,andthebrowserwillthentypicallypopupapassword

dialogaskingforauserIDandpassword.Thatinformationwillthen

besenttothecontainerintheheadersmentionedearlier.Theuser

IDandpasswordarenotencrypted;theyareinsteadmerelybase-64

encodedintheheaders.Thismeansthatyoushouldplanon

securingyourloginpage(ifnottherestofyoursite)throughHTTPS

aswediscussedearlier.

Form-basedAuthenticationForm-basedloginisanalternativeto

basicauthenticationwhereyouasadeveloperprovideanHTMLor

JSPpagethatprovidesaloginpagewiththecustomlookandfeelof

yourapplication.YourloginpagemustcontainanHTML
tag

thatperformsanHTTPPOSTtoaspecialactioncalled

j_securitycheckwithtwospecificallydefinedHTTPparameters,

j_usernameandj_password..WhentherequestisPOSTedto

thej_securitycheckURL,thecontainerwillverifytheuserID

andpasswordasinthebasicauthcase.



Certificate-basedAuthentication(HTTPSClientAuthentication)

Here,theclientbrowsermustpossessacertificateand

correspondingprivatekeytoidentifytheuser.Thisisuseful

particularlywhereyouwanttophysicallyrestrictallaccesstoyour

applicationtoaspecificsetofusers.However,youmustplanon

generatinganddisseminatingthecertificatestoyourusers.

DigestauthorizationThisisanoptionalauthenticationmechanism

specifiedintheservletspecificationthatWebSpheredoesnot

support.Digestauthenticationissimilartobasicauthentication,but

usesanencryptedpassword.Fewbrowserssupportthisoption.

Theparticularmechanismyouwanttosupportinyourapplicationis

specifiedonaweb-appbasisthroughtheWebdeploymentdescriptor

(web.xml).So,let'ssayyouwantedtosupportform-basedauthentication

inyourapplication.First,youwouldneedtoimplementanHTMLpageor

JSPpageasyourloginpage,followingtherulesdescribedearlier.You'd

alsowanttospecifyaloginerrorpage.Youwouldthenaddthefollowing

linestoyourweb.xmlfile:



FORM

MyForm-basedAuthentication



/login.html

/error.jsp







Howdoesthesecondpartofauthenticationwork?HowdoesWebSphere

knowwhatpeoplecorrespondtoparticularuserIDsandpasswordsandif

aparticularcombinationisvalid?Luckilyforyou,inmostcases,youdon't

havetodoanythingprogrammaticallytoperformthislookup.WebSphere

doesthisforyouthroughtheuseofuserregistries.Therearethree

optionsforuserregistriesinWebSphere:

WebSpherecanusethelocaloperatingsystem(UNIX,Linux,or

Windows)toobtainuserIDsandpasswords.

WebSpherecanuseanLDAP3.0compliantdirectoryserverto

provideuserIDsandpasswords.WebSpheredirectlysupportsthe

IBMDirectoryServer,LotusDominoEnterpriseServer,theSunONE

DirectoryServer,andWindows2000ActiveDirectory.However,

WebSpherecanbemadetoworkwithalmostanyLDAP3.0

directoryserverifyouprovidetheproperconfigurationinformation.

YoucanbuildyourowncustomuserregistrytolookupuserIDsand

passwordsfromafile,adatabase,oranyotherplaceyouchoose.

OnceauserhasbeenauthenticatedintoWebSphere,WebSphere

generatesaspecialclientcredentialtokeeptheuserfromhavingtolog

inagain.Thiscredentialuniquelyidentifiestheuserandiskeptina

cookiethatisstoredinmemoryontheuser'sbrowser.Ithasan

expirationtimeassociatedwithittokeepsomeoneelsefromfindingthe

cookieandusingittosurreptitiouslyloginastheoriginaluser(calleda

replayattack)afterwhichitisregeneratedandretransmitted.

Thereisaramificationassociatedwiththiswhenyouconsiderthe

differentauthenticationmechanisms.Ifauserdoesnotallowcookies

fromyoursiteinhisbrowser,theneveryWebrequestmustbe

reauthenticated.Thisworkswithbasic-authenticationsincetheuserID

andpasswordarestillintheHTTPheaderanditcanstillreauthenticate

everyrequest.Thiswillbeveryexpensivebutworkable.Informs-based

authentication,itwillforceyourapplicationintoaloopwhereeveryaction

goesbacktotheloginpage.So,themoralofthestoryiseitherinform



yourusersthattheymustleavecookiesturnedoniftheyareusinga

securedapplicationorplanonusingbasicorcertificate-based

authenticationandhavingaslowapplication.



29.1.3EJBClientMechanisms(JAAS)

Nowthatyou'veseenhowencryptionandauthenticationaredonealong

theApathfromtheWebbrowserintotheWebcontainer,youmaybe

wonderingwhathappensontheBpathfromanapplicationclienttothe

EJBcontainer(Figure29.1).Unlikeintheservletcase,thiscaseisnot

specifiedbytheJ2EEspecification.Themechanismforproviding

credentialstoanEJBcontainerisleftuptothevendor'sdiscretion.

InWebSphere5.0,IBMhaschosentousetheJAAS(Java

AuthenticationandAuthorizationService)APIsforprogrammaticloginfor

EJBs.JAASisaverybroadAPIthatallowsthedefinitionofcustom

authentication,authorization,andaccesscontrolmechanisms.

WebSpheredoesnotfullysupportalloftheJAASAPIinthisway.It

insteadsupportsalimitedsubsetoftheJAASAPI.Inthiscontext,the

supportthatisvaluableistheprogrammaticloginAPI.

Inmanycases,developershaveusedJAASinotherserverswithouta

predefinedsecuritymodel(likeTomcat)todefinetheirownlookup

mechanismsforuserIDsandpasswords.InWebSphere,aswehave

describedearlier,youwouldwanttouseauserregistryinsteadinthat

situation.Ineffect,JAASisamorestandards-compliantreplacementfor

theoldCORBAprogrammaticloginAPIsthatweresupportedin

WebSphere3.5andWebSphere4.0.

HowwouldyouactuallyuseJAASinpractice?Firstthereareanumber

ofstepsthatyouneedtoperformsuchassettingupasas.client.props

file,whichwillbeusedbyWebSpheresecurityinfrastructuretodetermine

thetypeofauthentication.Allofthesestepsaredescribedindetailinthe

WebSphereInfoCenter.Onceyouhaveperformedthesesetupsteps,

thenyoucanbeginusingtheJAASLoginContextAPI(Listing29.1).



Listing29.1TheJAASLoginContextAPI

LoginContextlc=null;

Stringusername="myUserName";

Stringpassword="myPassword"

Stringrealm="myRealm"

try{

lc=newLoginContext("WSLogin",



newWSCallbackHandlerImpl(myUserName,myRealm

}catch(LoginExceptione){



System.out.println("CannotcreateLoginContext."+e.g

//doanyerrorprocessinghere

}catch(SecurityExceptionse){



System.out.printlin("CannotcreateLoginContext."+se.

//doanyerrorprocessinghere

}

try{

lc.login();

}catch(LoginExceptionle){



System.out.printlin("CannotcreateSubject."+le.get

//doyourerrorprocessinghere

}



Thisexampleassumesthatyou'llprovideyourownusernameand

passwordtotheWSCallbackHandlerImpl.Thismeansthatyouwould

haveyourownSwing-baseddialogtoobtaintheuserIDandpassword

fromtheuserpriortocallingthisAPI.That'snotyouronlyoption.There

arealsotwootherCallbackHandlerimplementations:

WSStdinCallbackHandlerImplandWSGUICallbackHandlerImpl.The

formerreadsauserIDandpasswordfromstandardinput,whilethelatter

popsupadialogboxtoprompttheuserfortheuserIDandpassword.

Youcanusewhicheveroftheseismostappropriateforyourparticular

situation.

Justastherearesecuritycredentialsthatarepassedbackandforthfrom

thebrowsertotheWebcontainertoprovidetheauthenticationstatusofa

principal[1],therearesimilarcredentialsthatarepassedbetweenanEJB

clientandanEJB.InWebSphere,therearetwodifferentcredential

mechanismstochoosefrom:theCORBACommonSecure

Interoperability,2.0(CSIv2)protocol,whichisnewtoWebSphere5.0,

andtheWebSphereSecureAssociationService(SAS)protocol.Your

clientscanbeconfiguredtouseeitherorboth.Inpractice,thischoice

hashardlyanyimpactonyou;it'sonlyifyouneedtointeroperatewith

earlierversionsofWebSphereoranotherapplicationservervendorthat

you'llevercare.Theonlyresultyoucareaboutisthatcredentialsare

passedalongtransparentlywitheveryEJBcall.Thisisalsohowthepath

markedCinFigure29.1ishandled.IfyouareauthenticatedintoaWeb

container,WebSpherewillautomaticallyflowyourcredentialsintothe

EJBcontainerwithoutyourhavingtoprovideanyspecialcredentialsto

theEJBortheInitialContext(asisthecasewithsomeotherapplication

servers).

[1]Ajava.security.PrincipalistheJ2EErepresentationofanentitythatcanbe



authenticated.Thinkofitasbeinganameduser.



29.2J2EEAuthorization

Authorizationistheprocessofcontrollingaccesstoresources.Thebasic

processofauthorizationinvolvesanideacalledanaccesscontrollist,

whichisawayofspecifyingamappingbetweenusersandresources,

andshowingwhichusershaveaccesstowhichresources.

J2EEbasesitsauthorizationmodelonthenotionofarole.Youcanthink

ofaroleasajobthatausermightperform;forexample,clerk,manager,

orsupervisor.Eachusermayparticipateinmorethanonerole.

EachJ2EEcomponent(aservlet,oranEJB,forinstance)isassociated

withasetofabstract,developer-definedrolesthataregrantedaccessto

runthemethodsofaparticularEJB,ortouseaparticularservletorJSP.

Atdeploymenttime,theseabstractrolesaremappedtoactualusersthat

arestoredintheuserregistry.Tofacilitatethis,WebSpherekeepsa

mappingofgroupsandusersintheuserregistrytoJ2EEroles,soyou

mustconfigurethisaspartofthedeploymentprocessofyourapplication.

Here'showitworks.Rolesmayhavedifferentaccessrightstothesame

resource.Let'ssaywewereworkinginabankwherewehavetworoles:

tellersandloanofficers.Ifyou'realoanofficeryouneedtobeableto

viewaperson'sbankaccountbalancetodetermineifsheisagoodcredit

risk.So,ifwehadanaccountEJB,LoanOfficersshouldbeallowedto

callgetAccountBalance()onthatEJB.Ontheotherhand,Tellerscan

callnotonlygetAccountBalance()inordertotelladepositorhow

muchmoneysheinthataccount,butalsothedeposit()and

withdraw()methodstoupdatetheaccountbalance.

Likewise,ifwehadaservletcalledAdminServletthatallowedsomeone

toperformadministrationfunctionsinyourapplication,youwouldwantto

restrictaccesstothatservlettouserswhowereintheadminrole.Itis

importanttounderstandtherolesarespecifictoeachapplication.Thus,

theadminrolewearedescribingisunrelatedtotheadministratorrole

usedintheadministrationofWAS.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 29. J2EE Security in WebSphere

Tải bản đầy đủ ngay(0 tr)

×