incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonathan <jengb...@ryerson.ca>
Subject Re: 2.4 with kaukolu ldap auth/userdatabase to 2.8 migration
Date Thu, 23 Jul 2009 15:52:43 GMT
thanks a lot Andrew,

I figured it was something like this - the security logs are a bit 
confusing on this point.

The cookie assertion issue isn't a cookie assertion issue (contrary to 
my initial report).  There's something about Firefox/Chrome that often 
requires you to log-in twice.  I haven't done any further investigation 
into this, but the problem doesn't seem to manifest (so far) in IE.

thanks again for all your help,
Jonathan.

Andrew Jaquith wrote:
> Jonathan,
> 
> I did some tests and determined that the cause of the problem is
> probably on your end. Here's the deal:
> 
> - Container-managed authentication and authorization works by
> protecting a set of resources with auth-constraints
> 
> - Each auth-constraint lists one or more roles that are allowed to
> access those resources. Now here's the important point: these are
> CONTAINER roles, not JSPWiki roles.
> 
> - The default auth-constraint that protects Login.jsp (and thus
> triggers authentication) is protected by a sample container role
> called Authenticated. This is NOT the same as the JSPWiki role called
> Authenticated.
> 
> - Thus, if your container is not configured to return any roles, the
> container will NOT let you access Login.jsp and returns a 403
> (Forbidden), which directs you to Forbidden.html. This is exactly how
> the container is supposed to behave when a user is "unauthorized",
> which you are if you don't possess any container roles.
> 
> - However, even though you did not receive the proper container role
> to access Login.jsp, your session is STILL authenticated, and as such
> your HttpServletRequest possesses a UserPrincipal. JSPWiki sniffs this
> principal during the next request and says, "Aha! The user is
> container-authenticated" and prints out the G'day (authenticated)
> message.
> 
> Got it? Essentially, the container authenticates you, and JSPWiki
> figures that out. In between those two events, the fact that the user
> doesn't possess any container roles is what produces the 403.
> 
> The fix is simple. Just make sure that the role named in the
> auth-constraint is the same as one returned by your container. In our
> default web.xml, we assume that this role is called "Authenticated."
> If your default container role is different (for example, "person"),
> make sure the one in web.xml matches that role name.
> 
> I don't know what the root cause of your cookie authentication issue
> is. I could not reproduce it.
> 
> Andrew
> 
> On Wed, Jul 15, 2009 at 5:30 PM, jonathan<jengbrec@ryerson.ca> wrote:
>> heya too!
>>
>> The wiki page on container auth has been very, very helpful, yes.  Upon
>> further investigation, I think my issues are currently more role-related
>> than UserDatabase related.
>>
>> Container has been set up to authenticate to ldap, no roles have been
>> configured, web.xml is default container-managed config.  As soon as I log
>> in, I end up getting a forbidden page (on Login.jsp?redirect=Main).  If I
>> click "Better luck next time", I end up back on the main page,
>> "authenticated" (much like this problem:
>> http://www.mail-archive.com/jspwiki-user@incubator.apache.org/msg01892.html
>> - except I'm using Tomcat 5.5.15).
>>
>> If I look at my security log, I get the following entries only *after* I
>> click the "Better luck..." link on the Forbidden page:
>>
>> 2009-07-15 17:11:07,547 INFO - WikiSecurityEvent.LOGIN_AUTHENTICATED
>> [source=com.ecyrd.jspwiki.auth.AuthenticationManager@e4245,
>> princpal=org.apache.catalina.realm.GenericPrincipal jengbrec,
>> target=com.ecyrd.jspwiki.WikiSession@1f55105]
>> 2009-07-15 17:11:07,547 DEBUG - WikiSecurityEvent.LOGIN_AUTHENTICATED
>> [source=com.ecyrd.jspwiki.auth.AuthenticationManager@e4245,
>> princpal=org.apache.catalina.realm.GenericPrincipal jengbrec,
>> target=com.ecyrd.jspwiki.WikiSession@1f55105]
>> 2009-07-15 17:11:07,548 DEBUG - WikiSecurityEvent.PRINCIPAL_ADD
>> [source=com.ecyrd.jspwiki.auth.AuthenticationManager@e4245,
>> princpal=org.apache.catalina.realm.GenericPrincipal jengbrec,
>> target=com.ecyrd.jspwiki.WikiSession@1f55105]
>> 2009-07-15 17:11:07,548 DEBUG - WikiSecurityEvent.PRINCIPAL_ADD
>> [source=com.ecyrd.jspwiki.auth.AuthenticationManager@e4245,
>> princpal=com.ecyrd.jspwiki.auth.authorize.Role Authenticated,
>> target=com.ecyrd.jspwiki.WikiSession@1f55105]
>>
>>
>> It looks like I now should have the "Authenticated" role from the container
>> (though I don't seem to have it (according to the log, anyway) immediately
>> after clicking "login" which is strange).  However, I still get "Forbidden"
>> if I try and go to Edit.jsp or similar (the "Authenticated area" in
>> web.xml).
>>
>> After the initial "Forbidden", my wiki acls seem to work properly, but the
>> container-given Role ("Authenticated") doesn't seem to be working, even
>> though the logs appear to indicate that the role has been assigned.
>>
>> Thoughts on where to go from here?
>>
>> as always, many thanks,
>> jonathan.
>>
>>
>> Janne Jalkanen wrote:
>>> Heya!
>>>
>>> Does this help?
>>>
>>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
>>>
>>> /Janne
>>>
>>> On 14 Jul 2009, at 21:37, jonathan wrote:
>>>
>>>> Has anyone successfully done this?
>>>>
>>>> In 2.4 I'm using Kaukolu LDAPUserDatabase implementation to get user
>>>> data, so I have no local userdatabse.xml file to fall back on.  The existing
>>>> LDAPUserDatabase doesn't work with 2.8, of course.
>>>>
>>>> If you've done this, how are you handling the userdatabase portion under
>>>> 2.8?  We have a very large ldap database, but a relatively small number of
>>>> JSPWiki users, so migrating the ldap info into an xml (or even mysql)
>>>> userdatabase seems a bit like overkill (though this may be the simplest
>>>> route to take given my relative inability to recode the LDAPUserDatabase
>>>> stuff).
>>>>
>>>> Any thoughts appreciated.
>>>
> 

Mime
View raw message