[Java] Security en web applicaties

[-FoX-]

Voor een webapplicatie, die ik momenteel aan het ontwikkelen ben, zal er uiteindelijk ook een vorm van beveiliging aan te pas komen. In elke webapplicatie is dit natuurlijk min of meer van toepassing.
Nu zijn er ook tal van mogelijkheden om deze security in de applicatie te verweven, maar ik ben zelf niet zo goed op de hoogte van het security-aspect binnen Java webapplicaties in het algemeen. Daarom ook dit topic offcourse

Even in het kort iets over de webapplicatie in kwestie:
Het gaat om een administratieve groupware webapplicatie, waarin verschillende eindgebruikers op ingelogd kunnen zijn binnen hetzelfde bedrijf zeg maar. Natuurlijk hebben meerdere bedrijven toegang tot dit systeem en het moet in eerste instantie ook niet mogelijk zijn om data onderling tussen de bedrijven uit te kunnen wisselen.
Verder is het tussen de eindgebruikers wel mogelijk om elkaars data te zien, bvb: de ene kan de andere zijn agenda raadplegen en eventueel afspraken in elkaars agenda plannen.

Eén van de implementaties waaraan ik momenteel denk is het Spring Security framework (Acegi Security), aangezien ik ook al gebruik maak van Spring wel een goede mogelijkheid.
Wel hoor ik van verschillende personen dat het niet zo straightforward is om security met dit framework te implementeren door het andere manier van werken?

Verder heb je natuurlijk ook nog CMA, hoe denken jullie over deze vorm van security?
Het is natuurlijk wel jammer dat je dan niet zo simpel van appserver kan switchen, omdat deze security dan net aan deze server vasthangt

Wat nog een 'mogelijkheid' is, is om met een soort van filter-security te werken... dit werkt op zich wel, maar vind dit nogal een nasty oplossing.

Hoe is jouw kennis en ervaring met security?? Welke raad geef je me om op te letten en als je voor deze keuze zou staan, waar zou je dan voor opteren (en waarom )?

[Verwijderd]

Ik ben zelf ook wel geinteresseerd in dit onderwerp, maar heb eigenlijk niet zo veel toe te voegen op dit moment. Zelf gebruik ik altijd een simpel filter dat de ingelogde user uit de session haalt en aan de hand van simpele rights een Accessor object raadpleegt op de user een page wel of niet mag zien. Voor welke pages welke rechten nodig zijn hou ik een aparte externe ASCII file bij.

Mijn security is dus grotendeels dmv een filter en per page, maar enkele stukken uit mijn business logica gebruiken nog die simpele rights van het user object om andere dingen wel of niet te laten zien/toe te staan. Dit is allemaal redelijk adhoc, en ik wil eigenlijk wel eens naar een wat meer integrale oplossing gaan kijken.

Het valt me wel op dat de tweakers hier klaarblijkelijk niet zo geinteresseerd zijn in security?

[-FoX-]

Verwijderd schreef op woensdag 17 augustus 2005 @ 21:50:
Ik ben zelf ook wel geinteresseerd in dit onderwerp, maar heb eigenlijk niet zo veel toe te voegen op dit moment. Zelf gebruik ik altijd een simpel filter dat de ingelogde user uit de session haalt en aan de hand van simpele rights een Accessor object raadpleegt op de user een page wel of niet mag zien. Voor welke pages welke rechten nodig zijn hou ik een aparte externe ASCII file bij.

Mijn security is dus grotendeels dmv een filter en per page, maar enkele stukken uit mijn business logica gebruiken nog die simpele rights van het user object om andere dingen wel of niet te laten zien/toe te staan. Dit is allemaal redelijk adhoc, en ik wil eigenlijk wel eens naar een wat meer integrale oplossing gaan kijken.

Zo heb ik het inderdaad ook al gedaan, maar vooral voor kleinere webapplicaties dan (document management solution, intranet, ...), en op zich 'werkt' het op deze manier wel, maar erg proper is het niet imho . Het valt mij wel op dat er op het gebied van security nogal wat lak is, ook in het bedrijfsleven. Ik werk nu momenteel aan een groot internationaal clearing systeem en ook hier is er tot nu toe nog weinig sprake van security geweest. En we zijn nu toch al ongeveer een 750 mandagen er aan het ontwikkelen. Imho zou security er al vanaf het begin ingebakken moeten worden?

Het valt me wel op dat de tweakers hier klaarblijkelijk niet zo geinteresseerd zijn in security?

Inderdaad, ik zie hier ook maar weinig geadvanceerdere security topics passeren...
Maar ik kan er alleen geen echt goede reden voor verzinnen... in élke applicatie zit er toch wel een of andere vorm van security?

[Verwijderd]

-FoX- schreef op donderdag 18 augustus 2005 @ 12:26:
Inderdaad, ik zie hier ook maar weinig geadvanceerdere security topics passeren...
Maar ik kan er alleen geen echt goede reden voor verzinnen... in élke applicatie zit er toch wel een of andere vorm van security?

Je zou zeggen van wel. Er zijn wel wat topics geweest over hoe je moet beschermen tegen standaard aanvallen (SQL/Javascript injection voornamelijk), maar de echte security topics blijven veelal buiten beschouwing.

Ik moet toegeven dat ik er zelf geen expert in ben, maar als ik een beetje lees over security theorie in bv Operating Systemen dan kom ik dingen tegen als rights propagation, security breach isolation, access controll lists, etc. De eerste zegt bijvoorbeeld dat een user die rechten heeft deze wel of niet aan een andere user mag doorgeven (met als speciaal recht, het recht om rechten door te geven), isolation gaat over het feit dat -als- er een security breach is dat je dan hoogstens in je huidige context schade kan aanrichten maar niet daarbuiten kan komen.

Ik mijn eigen bedrijf ondervind ik aardig wat weerstand om het thema "security" op de agenda te krijgen als overkoepelend aandachts punt. Ik heb hier echt ruzie over gehad tijdens vergaderingen. De andere vinden dat als je "een beetje oplet bij het programmeren en zelf goed je werk controlleerd" dat het dan wel secure genoeg is allemaal. Het is tot nu toe een onmogelijke opgaven gebleken om de anderen te overtuigen dat we iemand moeten aannemen die speciaal op security gericht is en die security vanaf het begin in de (een) architectuur mee neemt.

[-FoX-]

Verwijderd schreef op donderdag 18 augustus 2005 @ 12:43:
Ik moet toegeven dat ik er zelf geen expert in ben, maar als ik een beetje lees over security theorie in bv Operating Systemen dan kom ik dingen tegen als rights propagation, security breach isolation, access controll lists, etc. De eerste zegt bijvoorbeeld dat een user die rechten heeft deze wel of niet aan een andere user mag doorgeven (met als speciaal recht, het recht om rechten door te geven), isolation gaat over het feit dat -als- er een security breach is dat je dan hoogstens in je huidige context schade kan aanrichten maar niet daarbuiten kan komen.

Ik ben er zelf ook geen expert in, vandaar dit topic, en buiten de simpele principes van security (login/passwd) ben ik er ook nog niet in aanraking mee gekomen.

Ik mijn eigen bedrijf ondervind ik aardig wat weerstand om het thema "security" op de agenda te krijgen als overkoepelend aandachts punt. Ik heb hier echt ruzie over gehad tijdens vergaderingen. De andere vinden dat als je "een beetje oplet bij het programmeren en zelf goed je werk controlleerd" dat het dan wel secure genoeg is allemaal. Het is tot nu toe een onmogelijke opgaven gebleken om de anderen te overtuigen dat we iemand moeten aannemen die speciaal op security gericht is en die security vanaf het begin in de (een) architectuur mee neemt.

Waarom krijg je zoveel tegenwind van jouw collega's? Wat zijn hun sterkste argumenten dan...?

Er zijn blijkbaar maar weinig mensen hier, die op een professionele manier met security bezig zijn. Eigenlijk best wel vreemd. Maar dan zou ik toch wel eens willen weten waarom precies?? Interesseert het hun niet of wat is de reden precies??

Is er overigens niemand die zijn commentaar over Acegi even kwijt wil?

[Verwijderd]

aangezien ik dit topic wel levend wil houden even onze manier van werken uit de doeken doen.

Ik werk aan een administratieve applicatie waar security heel belangrijk is. Onze logins gebeuren gewoon via de LDAP met windows paswoorden (er volgt een SSO systeem voor andere applicaties hier).

Er zijn 2 rollen in de LDAP: admin / gewone users (standaard rol). Via web.xml dwingen we admin rechten af voor alles onder /admin/...

Natuurlijk hebben we meer rollen, maar die zitten in onze eigen database. We hebben een eigen securitymotor die onze (belangrijkste) business objecten die alleen security interfaces implementeren als parameter aanvaard, samen met user credentials en een gevraagde ACTIE (Integer).
adhv rollen, parent child relations tussen business objecten, states van objecten en scopes (hierarchisch, persoon in die unit onder een andere unit waar je recht op hebt => recht is toegelaten) wordt dan geevalueerd of het recht wordt toegekend of niet.

verschillende rechten kunnen &&n bepaalde actie toelaten, maar de scopes kunnen verschillen. Al die gegevens van rechten, actions, scopes, ... zitten in onze eigen database.

Dus onze security zit zo goed als los van elk bestaand framework omdat er (toen, 3 jaar geleden) niets standaard was. Nu werken we nog steeds op basis van hetzelfde principe maar enkele implementaties verder en zijn nog steeds heel tevreden.


Ik denk niet dat zulke vereisten met een standaardoplossing konden aangepakt worden.

Voor simpeler applicaties levert ACEGI wel mooie filters en dergelijke denk ik (geen ervaring, ik heb mezelf maar een klein beetje ingelezen )

[-FoX-]

* kick *

Waarom security een van de meest onderschatte topics uit de hele IT is, weet ik eigenlijk niet goed. Maar het blijft toch een essentieel punt van iedere (web)applicatie.

Hoe zet jij je security op in een applicatie, houd je het simpel.. of ga je verder dan dat? Op welke manier pak je het aan?? Hands-on, best practices... laat eens wat horen!

[Alarmnummer]

Service achtige objecten (je remote interfaces) kan je uitstekend afschermen mbv Acegi (vooral als je Spring gebruikt) en je kunt Spring ook gebruiken op URL nivo. Alsje in de weblayer zit is het een beetje afhankelijk van welk framework je gebruikt aangezien sommige frameworks hun eigen faciliteiten hiervoor hebben.

[edit]
Acegi is dus niet alleen een URL filter. Acegi kan ook gebruikt worden om remote interfaces to proxieen met een security proxy.

[ Voor 24% gewijzigd door Alarmnummer op 18-10-2005 19:24 ]

[-FoX-]

Acegi is dus globaal in te zetten om een volledige applicatie van security te voorzien. Security is echter wel een ruime term, maar ik bedoel er eigenlijk vooral authenticatie en authorizatie mee.

Indien ik een URL heb: /context/editUser?id=34
Kan de gebruiker deze ook simpelweg veranderen, en er 35 van maken (maar hij mag deze user misschien helemaal niet editeren), dat wordt dan opgevangen met die URL filters?

Wat vind je zelf van het Acegi Security framework?

[Stephan Oudmaijer]

-FoX- schreef op dinsdag 18 oktober 2005 @ 19:44:
Acegi is dus globaal in te zetten om een volledige applicatie van security te voorzien. Security is echter wel een ruime term, maar ik bedoel er eigenlijk vooral authenticatie en authorizatie mee.

Indien ik een URL heb: /context/editUser?id=34
Kan de gebruiker deze ook simpelweg veranderen, en er 35 van maken (maar hij mag deze user misschien helemaal niet editeren), dat wordt dan opgevangen met die URL filters?

Wat vind je zelf van het Acegi Security framework?

Ik vind dat je authorisatie&autenticatie / filtering toch echt apart van elkaar moet zien.

Je security keuze is ook heel erg afhankelijk van de applicatie server waar je je applicatie op gaat draaien.

Ik geef zelf bij JBoss sterk de voorkeur voor JAAS. Redelijk standaard en voldoet goed in de meeste gevallen waar authenticatie&autorisatie nodig is. Je kunt de standaard J2EE role-based security koppelen aan een jaas-realm in JBoss.

In tomcat oid kun je ook een realm koppelen aan J2EE role-based security.

Acegi is ook best aardig. Heb er naar gekeken maar weet niet alle ins en outs. Voordeel van JAAS vind ik dat SSO vrij eenvoudig te implementeren is.

Daarnaast zul je je filtering van data (wie mag wat wel of niet zien) moeten implementeren. Ik regel die meestal in m`n services. Hier check ik of de principal (oid) wel de data mag zien. Zo niet dan gooi ik een mooie exception.

[-FoX-]

CK schreef op dinsdag 18 oktober 2005 @ 22:18:
Ik vind dat je authorisatie&autenticatie / filtering toch echt apart van elkaar moet zien.

Je security keuze is ook heel erg afhankelijk van de applicatie server waar je je applicatie op gaat draaien.

Dat hoeft niet zo te zijn, Acegi is hier een voorbeeld van.

Ik geef zelf bij JBoss sterk de voorkeur voor JAAS. Redelijk standaard en voldoet goed in de meeste gevallen waar authenticatie&autorisatie nodig is. Je kunt de standaard J2EE role-based security koppelen aan een jaas-realm in JBoss.

In tomcat oid kun je ook een realm koppelen aan J2EE role-based security.

Ok, ik wist wel dat dit bestaat, maar verder geef je geen verdere uitleg. Hoe configureer je je security instellingen? Waar houd je allemaal rekening mee? Welke pitfalls ben je al tegengekomen? Begin je simpel, werk je het daarna meer en meer uit... of hoe pak je dit precies aan? Dat is namelijk interessant om te weten.

Acegi is ook best aardig. Heb er naar gekeken maar weet niet alle ins en outs. Voordeel van JAAS vind ik dat SSO vrij eenvoudig te implementeren is.

Daarnaast zul je je filtering van data (wie mag wat wel of niet zien) moeten implementeren. Ik regel die meestal in m`n services. Hier check ik of de principal (oid) wel de data mag zien. Zo niet dan gooi ik een mooie exception.

Boet je daarmee niet erg in op performance?

[Alarmnummer]

-FoX- schreef op woensdag 19 oktober 2005 @ 09:52:
[...]
Boet je daarmee niet erg in op performance?

Dat ligt er aan. In serverside omgeving zonder weblayer, hoef je alleen je remote interfaces te securen. Remote interfaces zijn interfaces die je niet hoogfrequent aanroept (en verder ben je vaak veel tijd kwijt met het afhandelen van de aanroep omdat er bv db acties uitgevoerd worden, dus de overhead is tov de totale tijd vrij klein).

Op het moment dat je wel een weblayer hebt, dan secure je ook je locale service interfaces. Als ik heel erg eerlijk ben vind ik invloed van een weblayer op het ontwerp van een systemen te groot. Er worden veel consessies genomen waardoor je van een goed te beveiligen systeem, gewoon snel een puinzooi maakt. Ik ben bv ook tegen (vanuit ontwerp oogpunt) het direct binden op domain objecten door webforms (vooral de akelige 'save(entity)' methode is me echt een roestige spijker in het oog)

[ Voor 13% gewijzigd door Alarmnummer op 19-10-2005 10:09 ]

[-FoX-]

Alarmnummer schreef op woensdag 19 oktober 2005 @ 10:00:
Ik ben bv ook tegen (vanuit ontwerp oogpunt) het direct binden op domain objecten door webforms (vooral de akelige 'save(entity)' methode is me echt een roestige spijker in het oog)

Waarom?

[Alarmnummer]

-FoX- schreef op woensdag 19 oktober 2005 @ 12:02:
[...]

Waarom?

Op het moment dat je een save hebt, kan je er van alles in gooien en iedere extra check omzeilen.

code:

class EmployeeService{
     void giveRaise(Employee employee, int amount){
              employee.setSalary(employee.getSalary()+amount);
              employeeDao.save(employee);

              if(employee.getSalary()>ceo.getSalary())
                     sendMailTo(ceo,"Somebody is earning more");
     }

     void save(Employee employee){
          _empoyeeDao.save(employee);
     }
}

call1:
employeeService.giveRaise(jan,100000000000000);

call2:
jan.setSalary(100000000000000);//gebonden door de webrequest.
employeeService.save(jan);

Bij de 2e call krijgt de ceo geen email.

[ Voor 3% gewijzigd door Alarmnummer op 19-10-2005 12:35 ]

[-FoX-]

Alarmnummer schreef op woensdag 19 oktober 2005 @ 12:34:
Op het moment dat je een save hebt, kan je er van alles in gooien en iedere extra check omzeilen.

code:

class EmployeeService{
     void giveRaise(Employee employee, int amount){
              employee.setSalary(employee.getSalary()+amount);
              employeeDao.save(employee);

              if(employee.getSalary()>ceo.getSalary())
                     sendMailTo(ceo,"Somebody is earning more");
     }

     void save(Employee employee){
          _empoyeeDao.save(employee);
     }
}

call1:
employeeService.giveRaise(jan,100000000000000);

call2:
jan.setSalary(100000000000000);//gebonden door de webrequest.
employeeService.save(jan);

Bij de 2e call krijgt de ceo geen email.

Akkoord, maar dit is gewoon geen goed design. Die save(entity) zou helemaal niet aanspreekbaar mogen zijn voor de weblayer, en zou daarom ook altijd via de giveRaise(Entity, sal) moeten gaan.

Verder vind ik het best wel ok dat mijn domein objecten opgebouwd worden vanuit de weblayer. Mijn forms worden vertaald naar deze domein objecten die dan rechtstreeks naar de backend doorgevoerd worden. Daar is, imho, niets mis mee.

Maar ik ben er wel mee akkoord dat je hiermee een slecht design in de hand houdt.

[Alarmnummer]

-FoX- schreef op woensdag 19 oktober 2005 @ 15:02:
[...]

Akkoord, maar dit is gewoon geen goed design. Die save(entity) zou helemaal niet aanspreekbaar mogen zijn voor de weblayer, en zou daarom ook altijd via de giveRaise(Entity, sal) moeten gaan.

Hoe pass jij dan de informatie die je hebt gebonden aan je domain object, door naar de weblayer? En verder is je domain object nu al verneukt (met alle gevolgen van dien).

Verder vind ik het best wel ok dat mijn domein objecten opgebouwd worden vanuit de businesslayer. Mijn forms worden vertaald naar deze domein objecten die dan rechtstreeks naar de backend doorgevoerd worden. Daar is, imho, niets mis mee.

Ik zie het al een groot gaat waar je alles door heen kan kieperen zonder enige vorm van controle.

[-FoX-]

Alarmnummer schreef op woensdag 19 oktober 2005 @ 15:23:
[...]

Hoe pass jij dan de informatie die je hebt gebonden aan je domain object, door naar de weblayer? En verder is je domain object nu al verneukt (met alle gevolgen van dien).

Maak die vraag eens konkreter.

Ik zie het al een groot gaat waar je alles door heen kan kieperen zonder enige vorm van controle.

Ik denk dat we verschillende zaken bedoelen, maar als je voor dat groot gat een aantal guards zet is er toch geen probleem? Ik zie niet direct in hoe je dit anders zou doen?

offtopic:
The duck is no more...

[Alarmnummer]

-FoX- schreef op woensdag 19 oktober 2005 @ 16:07:
[...]

Maak die vraag eens konkreter.

Ik bedoelde businesslayer (zal wel niet op de send knop hebben gedrukt toen ik de wijziging doorvoerde).

Hoe stuur jij informatie dat je via een formulier (bv... bewerken van Employee) hebt verkregen door naar de businesslayer?

offtopic:
The duck is no more...

Idd.. vond die zwerver meer bij me passen.

[-FoX-]

Alarmnummer schreef op woensdag 19 oktober 2005 @ 16:31:
Hoe stuur jij informatie dat je via een formulier (bv... bewerken van Employee) hebt verkregen door naar de businesslayer?

Ik werk bijvoorbeeld met een bepaalde formbean die alle waardes bevat van het gesubmitte formulier. In mijn web-model voer ik dan de juiste validaties door, en stop alle nuttige velden in een dto, vo, bean, whatever.. Die vo gaat dan naar mijn service laag, waar hij verder afgehandeld wordt.

Het ging mij er meer om dat je een save(Entity) ter beschikking stelde van je web layer, terwijl deze die method eigenlijk helemaal niet hoort aan te spreken aangezien hij die business specifieke checks dan omzeilt.

[Bbfreak]

* kick *

Ik ben bezig met Security binnen een Java webapplicatie en heb nog geen goede oplossing.
Ik maak gebruik van Spring dus heb gekeken naar Acegi. Omdat mijn Spring ervaring
in de kinderschoenen staat heb ik erg veel moeite om het goed te configureren.
Goede tutorials ontbreken imho. Of zie ik dit verkeerd?

Jullie hebben het over filters? Kan ik hier ergens goede info over vinden?

[TheRebell]

volgens mij heb je voor webservice ook zoiets als WS-Security. Hier zijn ze nog wel allemaal mee bezig, maar het heeft betrekking om de brakke beveiliging binnen webservices. Ik denk dat je hier wel iets over kunt vinden

[Bbfreak]

TheRebell schreef op dinsdag 15 november 2005 @ 13:18:
volgens mij heb je voor webservice ook zoiets als WS-Security. Hier zijn ze nog wel allemaal mee bezig, maar het heeft betrekking om de brakke beveiliging binnen webservices. Ik denk dat je hier wel iets over kunt vinden

Maar dit is niet wat ik zoek. Ik wil gewoon simpele JSP beveiliging.
Het is nogal lastig omdat ik Spring gebruik die alleen maar met http://localhost/appname/blaat.html werkt en je niet op /secure kunt beveiligen of iets. Dan had ik het via Tomcat kunnen doen.
Als iemand van jullie weet hoe dit wel moet dan hoor ik het graag.

Ik denk dat de snelste oplossing misschien is om zelf een login pagina te maken en
deze in de Spring MVC te controlleren en vervolgens een HttpSession object te vullen.
Deze kun je elke pagina controleren. Of denk ik nu weer te makkelijk?

[Verwijderd]

Ik denk dat het eenvoudigste is om een aparte filterservlet te gebruiken. Deze configureer je in je web.xml , zo bepaal je welke urls (of allemaal eventueel) via deze filter passeren. Het is eigenlijk gewoon een servlet die wordt uitgevoerdt, vooraleer je daadwerkelijk op je servlet/jsp/action/whatever uitkomt.

Hoe je die filter instelt, bekijk JAAS en het gebruik van Realms. Welke applicatieserver gebruik je ?

[Bbfreak]

Verwijderd schreef op dinsdag 15 november 2005 @ 14:07:
Ik denk dat het eenvoudigste is om een aparte filterservlet te gebruiken. Deze configureer je in je web.xml , zo bepaal je welke urls (of allemaal eventueel) via deze filter passeren. Het is eigenlijk gewoon een servlet die wordt uitgevoerdt, vooraleer je daadwerkelijk op je servlet/jsp/action/whatever uitkomt.

Hoe je die filter instelt, bekijk JAAS en het gebruik van Realms. Welke applicatieserver gebruik je ?

Ik gebruik Tomcat. Ik zal daar eens naar kijken.
JAAS heb ik op school gebruikt voor Swing applicaties en dus had ik er ook voor webapplicaties
naar gezocht maar de zoekresultaten vielen me erg tegen.

[Verwijderd]

Mijn kennis van tomcat is beperkt, maar ik vermoed dat die standaard geen realm zal hebben(could be wrong). Ik heb de indruk dat je het eenvoudig wil houden, dus kan je misschien simpelweg in je filter verifiëren of er een specifiek attribuut in je sessie aanwezig is (de waarde daarvan kan je van de tijd e.d. doen afhangen), wanneer dit element niet aanwezig is stuur je de persoon naar de loginpagina, indien dit succesvol is, zet je de waarde in de sessie. Lijkt me niet superveilig, maar afhankelijk van de situatie kan dit volgens mij voldoende zijn.

edit: zie net dat je al zelf +- op dit idee bent gekomen :-) , deels overbodige post dus

[ Voor 8% gewijzigd door Verwijderd op 15-11-2005 15:51 ]