Re: [Geoserver-users] [gs 2.2.1] Failure to change authentication filters

[<chr...@nv...>]

Hi Landry, answers inside

Zitat von Landry Breuil <br...@cr...>:

> On 10/30/12 16:07, chr...@nv... wrote:
>> Hi Landry
>
> (going private, fw to the list if you want..)
>
>> The DEBUG level is correct in this situation. The first messages is
>> because you log in as root with a wrong password. Next, the system
>> passes the user/password combination to the configured user/group
>> service  to see if there is a "normal" user called root. Since there is
>> no such user, you see the second exception.
>
> But then, why does this happen even as 'admin' user ?

As an admin user, the first exception should not be there. Please open  
a JIRA ticket.

> If i understand correctly
> http://docs.geoserver.org/stable/en/user/security/auth/web.html, is it
> because the 'root' provider is always tested before the default
> username/password provider ?
Yes
> And since we cant of course disable the root provider, wouldnt it be
> wise to 'silence' the two exceptions in case full debug is enabled, to
> not confuse an admin (like me) reading the log ?

About the second exception. The log indicates an invalid password, but  
the real reason for this exception could be

1) an invalid password
2) an unknown user

Would you prefer having special information in the log file for 2) ?.   
You can add this to the JIRA issue.

>
>> Landry, at the moment I am working on the GUI for configuring
>> authentication filters and I know there are some things to fix. I would
>> propose to suspend your testing and I give you a ping if I fixed it.
>
> Sure, i was also planning to test the cas auth filter soon, so i'll
> definitely need to dig more into both. if needed i'll rebuild gs from
> the 2.2.x github branch. let me know when you have some kind of doc for
> the gs cas setup, because atm i have several interrogations in my
> usecase within georchestra:

After fixing the filter chain gui, the next step is to finish the CAS  
extension. This extension should not have been uploaded to the  
download page because it is not ready yet.

>
> - the georchestra security-proxy handles all the incoming requests,
> sets some http headers (sec-username, sec-roleS (yes, several roles
> separated by a comma, not only one.. annoying for geoserver ?)) i
> suppose that can be used for a http header auth filter for testing
> purposes, let aside the jsessionid ticket ?

Yep, the http header authentication can be used for this scenario.  
Unfortunately, this filter uses the semi colon for separating roles.
But you can chance this in the applicationSecurityContext.xml file.

> Finally, it also allows OWS requests to geoserver based on some rules,
> and redirects the requests to geoserver/geonetwork.
>
> - the authentication goes through a cas server, and clicking on the
> login/logout button within geonetwork redirects to it - does the cas
> authentication filter for geoserver achieves the same ?

Yep, proxy ticket support included.

>
> - is there a way to specifically enable verbose log for the auth
> filters chain (see the filters/parameters/username/passwd passed) ?
> Since the *LOGGING.properties are bundled within geoserver, they're not
> changeable without a rebuild, or they can be overriden by a file in the
> datadir ?

I am not an expert here, please open a new thread on the mailing list.

>
> Thx for you work on geoserver!
Thx for your report !
>
> -- 
> Landry Breuil
> Mouton a 5 pattes du CRAIG
>
Christian



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.