[JBoss] Authenticatie form + client certificate

[JKVA]

Het probleem. We hebben een applicatie welke door verschillende soorten gebruikers gebruikt wordt. Zowel intern op het intranet, als vanaf PC's her en der in het land (wel in veilige kantoren). Die PC's her en der in het land worden gebruikt voor callcenters en die mensen hebben het nogal druk, dus die willen niet steeds inloggen. Als je gewoon een browser opent op een willekeurige interne PC, dan dien je gewoon in te loggen.

Dat inloggen is niet zo'n probleem, maar mijn vraag is of het mogelijk is om binnen één webapplicatie meerdere typen authenticatiemechanismen te hangen.

Deze link zegt dat je dan twee webapplicaties moet maken, één met de daadwerkelijke content en de andere alleen voor het inloggen. Dit oogt echter een beetje als een wanoplossing, dus ik zoek naar een nette manier.

[momania]

Al naar Acegi gekeken? (Ofwel: Spring security)

[JKVA]

momania schreef op dinsdag 12 juni 2007 @ 07:57:
Al naar Acegi gekeken? (Ofwel: Spring security)

Het woord Spring mag ik hier niet gebruiken. Don't ask why.

[momania]

Ok, zeg maar dat dat erg dom is dat tegen diegene die het je verbied

[JKVA]

momania schreef op dinsdag 12 juni 2007 @ 09:43:
Ok, zeg maar dat dat erg dom is dat tegen diegene die het je verbied

Sorry, geen optie. Dat is slecht voor mijn beoordelingsgesprek.

Maar niemand ervaring met standaard J2EE A&A?

[D-Raven]

Ik ben daar zelf ook tegen aangelopen in mijn schoolgaan tijd Wat ik me er nog uit kan herinneren is dat we een portal applicatie hadden gemaakt die de authenticatie afhandelde en de applicatie zelf welke zijn authenticatie credentials van de portal app kreeg.

Maar met die loginmodules. Wat belet je om na de authenticatie van die loginmodule niet zelf nog eens een authenticatie slag te doen ? Dit had ik toendertijd ook gedaan namelijk. De aparte portal site was er voor andere redenen. Ja je zult het een en ander aan custom code moeten schrijven om dat te bewerkstelligen.
Maarja, jij bent degene die zegt dat je werkgever je verbied om Spring te gebruiken....

offtopic:
Als mijn werkgever mij verbied om een framework te gebruiken welke hele goede oplossingen heeft voor een business probleem..... Hell, als hij mij dwingt om een ruk oplossing te implementeren terwijl er geen HELE goede reden voor is dan denk ik niet dat ik nog lang daar zou willen werken. Voor hem 1000 andere atm

[JKVA]

D-Raven schreef op dinsdag 12 juni 2007 @ 12:38:
Ik ben daar zelf ook tegen aangelopen in mijn schoolgaan tijd Wat ik me er nog uit kan herinneren is dat we een portal applicatie hadden gemaakt die de authenticatie afhandelde en de applicatie zelf welke zijn authenticatie credentials van de portal app kreeg.

Maar met die loginmodules. Wat belet je om na de authenticatie van die loginmodule niet zelf nog eens een authenticatie slag te doen ? Dit had ik toendertijd ook gedaan namelijk. De aparte portal site was er voor andere redenen. Ja je zult het een en ander aan custom code moeten schrijven om dat te bewerkstelligen.
Maarja, jij bent degene die zegt dat je werkgever je verbied om Spring te gebruiken....

Dat heeft te maken met de informatiebeveiliging hier. Zelf dingen fabriceren is geen optie. Gebruikmaken van proven technology wel, onder andere op gebied van security. Daar ben ik het ook wel mee eens trouwens. Daarom zoek ik naar de "gemakkelijke weg", dus iets van meerdere loginmodules chainen ofzo.

offtopic:
Als mijn werkgever mij verbied om een framework te gebruiken welke hele goede oplossingen heeft voor een business probleem..... Hell, als hij mij dwingt om een ruk oplossing te implementeren terwijl er geen HELE goede reden voor is dan denk ik niet dat ik nog lang daar zou willen werken. Voor hem 1000 andere atm

offtopic:
Overigens, ik ben heel tevreden met mijn werkgever, maar ik zit gedetacheerd bij een bedrijf dat slechte ervaringen heeft met XML. En ja, Spring heeft wel iets met XML te maken. De personen die iets over deze zaken te zeggen hebben zijn tegen Spring. Ik heb er geen inspraak op en ga niet tegensputteren, het is mijn rol niet en ik wordt er niet voor betaald. Bovendien moeten dergelijke standaarden en tools maar intern gekozen worden. Is aan de andere kan ook weer leuk, zie je weer eens iets anders.

[D-Raven]

De informatiebeveiliging.. hmm dat vindt ik een interessant standpunt van hun.
Wie garandeert namelijk dat loginmodules die door iemand anders (hetzij opensource, hetzij commercieel) ontwikkeld zijn voldoen aan de veiligheid eisen die gesteld worden door het bedrijf waar jij nu gedetacheerd zit ?

Als het te maken heeft met dat jij niet de gegevens mag zien of mag weten hoe de authenticatie in detail werkt. Tjah beetje nutteloos als je het mij vraagt. Als je echt kwaad wilt dan is de kennis over welke login modules gebruikt worden al genoeg. Je kunt tenslotte in je eigen tijd die dingen helemaal gaan doorlichten op exploits e.d.

Met zelf iets ontwikkelen kun je met in-house veiligheid experts precies bepalen hoe veilig jou stukje code is. Plus alle voordelen van zelf de source code hebben enzow.
Laat ik het zo zeggen. Ik kan meer redenen bedenken om zelf iets te maken dan redenen om het niet te doen. Ook als de desbetreffende ontwikkelaar gedetacheerd is.

Ik snap jou positie overigens heel goed. Zit zelf ook geregeld in die situatie en ben het helemaal met je eens wat betreft je standpunt. Maar als ik zelf in zo'n situatie zit kan ik het meestal niet laten om ongevraagd mijn mening te geven (mocht er over gediscussieerd worden in mijn bijzijn ).
Overigens heb ik sterk het gevoel dat het een paar kortzichtige mensen zijn die "personen die iets over deze zaken te zeggen hebben".
Slechte ervaringen met XML zegt volgens mij meer over de manier waarop ze het gebruikt hebben dan over XML zelf. Waarmee ik inderdaad suggereer dat ze het zichzelf aangedaan hebben

Maargoed. Ik heb verder zo geen ideeën meer om je verder te helpen. Heel veel succes in ieder geval