[javabeans] Authenticatie lukt niet?

[Nappa]

Ik heb een probleem met de authenticatie van users bij session beans, misschien dat iemand wat tips voor mij heeft. Het probleem is het volgende.

Ik heb een servlet gemaakt, waarin een session bean wordt aangemaakt. Nu is het de bedoeling dat gebruikers eerst geauthenticeerd worden. Volgens de tutorial is dit mogelijk:

If a web component is protected, you may specify three types of authentication: basic, form, and certificate. With basic authentication, the server instructs the Web browser to prompt for the user name and password. (..knip..)
In all types of authentication, if the web component calls as enterprise bean, the call is associated with the authenticated user.

In de deploytool heb ik nu dus alvorens de webcomponent te deployen 'Basic' aangegeven bij 'User Authentication'. Ik krijg echter bij het laden van de pagina geen enkele username/password prompt of iets van dien aard. Weet iemand waar dit aan kan liggen???

[Nappa]

Niemand enig idee??

[Bobco]

Op donderdag 20 juni 2002 14:40 schreef Nappa het volgende:Niemand enig idee??

Niet dat ik je nu meteen verder zal kunnen helpen, maar welke applicatie server gebruik je? Misschien is het ook handig om wat te laten zien van je deployment descriptor. Een stukje XML zegt soms meer dan 1000 woorden

[mbravenboer]

Bobco: Een stukje XML zegt soms meer dan 1000 woorden

die is erg leuk (in relatie tot de vaak gehoorde kritiek op de verbositeit van XML).

[Nappa]

Hier de deploymet descriptor.

code:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
' 'http://java.sun.com/dtd/web-app_2_3.dtd'>

<web-app>
  <display-name>VoterWebApp</display-name>
  <servlet>
    <servlet-name>VoterServlet</servlet-name>
    <display-name>VoterServlet</display-name>
    <servlet-class>VoterServlet</servlet-class>
  </servlet>
  <session-config>
    <session-timeout>30</session-timeout>
  </session-config>
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Default</realm-name>
  </login-config>
  <ejb-ref>
    <ejb-ref-name>voter</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>VoterHome</home>
    <remote>Voter</remote>
  </ejb-ref>
</web-app>

Hierin staat toch wel duidelijk aangegeven wat de authenticatie methode is, en in welke realm. Het is toch niet zo dat je automatisch als gast inlogt ofzo?

[Nappa]

Ik heb ook nog wat op het web rondgezocht, weinig concrete oplossingen te vinden helaas.
Ik zag wel dat in veel van die deployment descriptors (of eigenlijk ben ik er maar twee tegengekomen ) dat er naast die <login-config> ook nog <security-constraint> genoemd wordt. Moeten we daar soms gebruik van maken? Maar hoe dan?

[Bobco]

Op donderdag 20 juni 2002 22:44 schreef Nappa het volgende:
Ik heb ook nog wat op het web rondgezocht, weinig concrete oplossingen te vinden helaas.
Ik zag wel dat in veel van die deployment descriptors (of eigenlijk ben ik er maar twee tegengekomen ) dat er naast die <login-config> ook nog <security-constraint> genoemd wordt. Moeten we daar soms gebruik van maken? Maar hoe dan?

[Disclaimer: ik heb hier nog nooit iets mee gedaan, dus ik blaat ook alleen maar de documentatie na.]

Ik denk dat je wel op de goede weg zit. Beveiliging bestaat uit twee gedeelten: authenticatie (weten met wie je praat) en authorisatie (weten wie wat mag doen). Als ik jouw configuratie zo zie dan geef je wel aan dat clients geauthenticeerd moeten worden met basic authentication, maar nergens dat een client ook geauthoriseerd moet zijn om je applicatie te benaderen.

Kortom, ik denk dat je inderdaad een security-constraint moet aanbrengen op je web-application. Sun schrijft daar over in de J2EE blueprint. HTH.

[Nappa]

Op vrijdag 21 juni 2002 09:17 schreef Bobco het volgende:

Ik denk dat je wel op de goede weg zit. Beveiliging bestaat uit twee gedeelten: authenticatie (weten met wie je praat) en authorisatie (weten wie wat mag doen). Als ik jouw configuratie zo zie dan geef je wel aan dat clients geauthenticeerd moeten worden met basic authentication, maar nergens dat een client ook geauthoriseerd moet zijn om je applicatie te benaderen.

De applicatie zit zo in elkaar, dat wanneer een gebruiker geauthenticeerd is door de server, hij verder geen beperkingen heeft op de operaties die hij op de beans mag uitvoeren; het enige dat dus nodig is, is dat de server weet met wie hij praat. Dan is alleen authenticatie toch genoeg?
Of is het zo, dat als de resources niet beschermd zijn, deze door iedereen aangeroepen kunnen worden ongeacht of het nou een geauthenticeerde user is of een (ongeauthenticeerde) anonieme user? In dat geval zal ik dan waarschijnlijk wel de resources moeten beschermen en roles moeten gebruiken.

Blijft toch wel lastig dit (en al helemaal omdat mn deploytool om de haverklap vastloopt )

[Bobco]

Op vrijdag 21 juni 2002 13:06 schreef Nappa het volgende:
[..]
Of is het zo, dat als de resources niet beschermd zijn, deze door iedereen aangeroepen kunnen worden ongeacht of het nou een geauthenticeerde user is of een (ongeauthenticeerde) anonieme user? In dat geval zal ik dan waarschijnlijk wel de resources moeten beschermen en roles moeten gebruiken.

Ik denk dat je de situatie hier goed beschrijft. De web-app weet dat de authenticatievorm BASIC is en zal dat dus melden aan de webserver op het moment dat er toegang moet worden verleend tot een resource waarvoor authorisatie nodig is.

Omdat jij blijkbaar voor geen enkele resource hebt aangegeven dat er authorisatie nodig is, zal je webcontainer dus ook nooit de webserver opdracht geven om een inlog-schermpje te laten zien.

En voor wat betreft het vastlopen van het deployment-tool: kijk eens naar Ant. Kun je volgens mij ook prima deployment mee doen...

[Nappa]

Yes! Hij doet het nu inderdaad! Het lag inderdaad aan het toevoegen van de security constraints aan de resources. Bedankt!

[Nappa]

De authenticatie werkt nu dus, maar ik zit nog met een klein probleempje. Als je dus ingelogd bent, dan is het mogelijk om de naam van de user te achterhalen middels EJBContext.getCallerPrincipal().getName() of HttpServletRequest.getUserPrincipal().getName().

Nu wil ik in de servlet dus de naam van de user ophalen. Hiervoor gebruik ik dus:

code:

caller =  HttpServletRequest.getUserPrincipal().getName();

Dit is echter niet mogelijk, want getUserPrincipal is static terwijl de servlet non-static is. Ik kan ook geen HttpServletRequest object instantieren omdat dit een abstracte class is.
Hoe moet ik dit dan oplossen?

[Verwijderd]

probeer het eens met het request-object; deze is in de doPost method beschikbaar, want ik neem aan dat de header
hiervan er ongeveer als volgt uit zal zien:

"protected void doPost (HttpServletRequest request,...) {"

verder weet ik het ook niet hoor..

[Nappa]

Op vrijdag 21 juni 2002 17:02 schreef nronaldvdberg het volgende:
probeer het eens met het request-object; deze is in de doPost method beschikbaar, want ik neem aan dat de header
hiervan er ongeveer als volgt uit zal zien:

"protected void doPost (HttpServletRequest request,...) {"

verder weet ik het ook niet hoor..

Hmmmmz.... Natuurlijk!!!

thx