Newbie trying to understand

[kantorn]

Been reading the docs over and over, but I don't understand how and where the SecureContext and related objects are created and put into "a well-known" location. I understand there is a Filter implementation for this but how do you create the secure context and put it into location wellknown yourself?

The following usecase is wanted:

A view with a username and password is shown to the user. A LoginController's onSubmit() method should then take these two, compare the to a batabase, assemble an implementation of AuthenticationDao and put it in HttpSession or what it is it should do here

I'm completely lost here, and it feels that I'm trying to make it more complicated than it really is. At this stage I need to understand mora than just using HTTP Session Authentication or HTTP Basic Authentication, because my LoginFormController have to be able to perform other tasks.

Could someone help me pls? Relevant Controller code would be good, I fell that Acegi sample app doesn't give much information on this first crucial step (the un/pwd thing)

Thanks!

[Ben Alex]

I would recommend you try to use the Acegi Security infrastructure classes as much as possible. ie: HttpSessionIntegrationFilter, which for each request will obtain an Authentication from the HttpSession, put it in the ContextHolder, proceed with the request, then at the end of the request copy the Authentication in the ContextHolder back into the HttpSession for the next request, and put null into the ContextHolder.

When you say your Controller needs to do other things, may I ask what? If you using the standard Acegi Security classes and DaoAuthenticationProvider, it will publish various AuthenticationEvents. Perhaps you could write an ApplicationListener which will consume those events (see LoggerListener for an example). Alternatively, could you subclass DaoAuthenticationProvider? It has various protected methods intended to allow customisation of the authentication handling.

The big advantage of one of these two options is you are HTTP authentication mechanism independent. So if you need to present credentials via BASIC authentication or FORM authentication, the same classes work with both. Also, you save a lot of work as all the Acegi Security classes will handle the ContextHolder integration properly for you. ContextHolder interaction is a source of confusion for many users, so it's not something you want to replicate unless you completely understand what the framework classes are doing.

If you really want to do it in a Controller, just have your Controller build the Authentication token and put it in the ContextHolder. The HttpSessionIntegrationFilter will move it out of the ContextHolder each request. NB: Your Controller should delegate to an AuthenticationManager to process the request and build the Authentication token. This is because AuthenticationManager must produce an Authentication which, when presented on subsequent requests by an AbstractSecurityInterceptor, will be able to re-authenticate the token.

[kantorn]

OK, thanks a lot!
So you don't recommend implementing a loginfunctionality of your own through a Spring controller?
So yoyu then use HTTP Basic Authentication throgh a webpage form? (Docs paragraph 1.9.3) And as long as you do everything is handled automagically?
*still confused but on a higher level*

[Ben Alex]

The SecurityEnforcementFilter has an AuthenticationEntryPoint. The entry point "launches" your default authentication mechanism by sending a browser redirect or status message (ie require BASIC login) as appropriate. Your browser does its thing (redirects or collects you credentials) and sends them back. An Acegi Security filter detects the browser's response and processes it. The filter creates an Authentication "request" which contains the username and password, passing it to the AuthenticationManager. If all goes well, the AuthenticationManager will return a fully populate (ie with GrantedAuthority[]) Authentication. That will then be placed into the ContextHolder by the filter. Finally, the filter will redirect to wherever you were trying to go when the authentication exception occurred. The protected page/method etc will then proceed (or cause a 403 if an authorization as distinct from authentication failure). At the end of the request, the HttpSessionIntegrationFilter will copy the Authentication from the ContextHolder and into the HttpSession, ready for the next request. The next request for that HttpSession will then come in, and HttpSessionIntegrationFilter will copy the Authentication from the HttpSession into the ContextHolder and request proceeds. The process then continues.

[kantorn]

Thanks, Ben, I'll try to "digest" this information.
Can't guarantee that I won't be back asking newbie stuff later though..

[Ben Alex]

Thanks, Ben, I'll try to "digest" this information.
Can't guarantee that I won't be back asking newbie stuff later though..

No probs, feel free.

[callamits]

Hi,

I have a similar login application, an Admin Web Console for adminstration. The usecase is:

Login using username and password, maintain the information in session if succesful. Subsequent operations should verify the authenticity of the user.

Going thru the document, i saw two options:

1) Use the Controller interface and directly access the HttpSession object and save/use the auth info. But this becomes messy and not a good solution.

2) The other is using Acegi Security infrastructure as you suggested, this seems to be heavy a solution.

Is there any other controller or option (For example Interceptor which verifies the HttpSession once saved) ?

Thanks in Advance,
Amit

[bling683]

Ben,

I'm having a similar issue/misunderstanding along with my project. Here is the use case:

I have "two" layers of authentication (don't worry about these they work fine). If the user is validated throw the first layer but not the second layer, they will be redirected to a registration page. The problem is, the requirements does not allow the user to re-type their username/password in that new registration page. I have to somehow pass that over in the back-end so when the user hits 'Submit' the username would be saved automatically in that record field. I've tried to pass it by setting the Attribute in the session but that would not work. Could this be done or is there another possible solution to this? BTW, I'm using a dinosaur .60 version of Acegi. Due to extreme time constraints, upgrading would really be my last option. If anyone could solve this, that would be great.