Hi Mauro, the above message is not complete, it was sent by accident.
The current hierarchy is
GeoServerPreAuthenticationFilter
- GeoServerJ2eeAuthenticationFilter
- GeoServerPreAuthenticatedUserNameFilter
---- GeoServerCasAuthenticationFilter
---- GeoServerRequestHeaderAuthenticationFilter
---- GeoServerX509CertificateAuthenticationFilter
I thought about the following
GeoServerPreAuthenticationFilter
- GeoServerPreAuthenticatedUserNameFilter
---- GeoServerCasAuthenticationFilter
---- GeoServerRequestHeaderAuthenticationFilter
---- GeoServerJ2eeBaseAuthenticationFilter
----------- GeoServerX509CertificateAuthenticationFilter
----------- GeoServerJ2eeAuthenticationFilter
There is a new abstract class GeoServerJ2eeBaseAuthenticationFilter adding
the J2EE "isUserInRole" stuff and adding a new J2EE RoleSource. I assume
the same behavior concerning roles independent of how you authenticate
against the J2EE Container.
I think you have to mirror this hierarchy for the config classes and the
GUI classes.
I hope this is understandable to you, otherwise please ask :-)
Chrilstian
On Wed, Oct 9, 2013 at 4:48 PM, Christian Mueller <
[email protected]> wrote:
> Hi Mauro
>
> The current hierarchy is
>
> GeoServerPreAuthenticationFilter
> GeoServerJ2eeAuthenticationFilter
>
>
>
>
>
>
> On Wed, Oct 9, 2013 at 2:48 PM, Mauro Bartolomeoli <
> [email protected]> wrote:
>
>>
>>
>>
>> 2013/10/9 Christian Mueller <[email protected]>
>>
>>> Hi Mauro
>>>
>>> I had a look at your pull request, nice work !
>>>
>>
>> Thanks :)
>>
>>
>>>
>>> I am missing some code in FilterConfigValidator and a proper test case.
>>> (As an example, a role service of type GeoServerJ2eeRoleService can only
>>> be used with RolesTakenFrom.J2EE)
>>>
>>
>> Ok, I wasn't aware of the Validator, taking a look at it.
>>
>>
>>>
>>>
>>> I am feeling uncomfortable with RolesTakenFrom.Both. The problem is that
>>> you can have role name clashes. All authentication mechanisms use exactly
>>> one role service to avoid this. The solution would be to invent qualified
>>> role names, but this is a lot of work.
>>>
>>> Personally, I would go a slightly different way. All proxy
>>> authentication filters except the J2EE filter allow roles to be fetched
>>> from
>>>
>>> 1) a role service
>>> 2) a user/group service
>>> 3) an HTTP header attribute
>>>
>>> If we want to open the J2EE filter for 1) we should also allow 2) and 3).
>>>
>>
>> Yes, it seems a good generalization for authentication filters.
>>
>>
>>>
>>> I would try to change the superclass
>>> of GeoServerJ2eeAuthenticationFilter
>>> to GeoServerPreAuthenticatedUserNameFilter.
>>>
>>> The J2EE filter would inherited possibilities 1),2) and 3) and add the
>>> J2EE Container as possibility number 4.
>>>
>>
>> So, what you would do is add a new value to the RoleSource enum (J2EE)
>> and implement the role binding of the j2ee option inside
>> GeoServerPreAuthenticatedUserNameFilter is it correct?
>> Sounds fine to me. This way we can get rid of RolesTakenFrom and
>> let GeoServerJ2eeAuthenticationFilter only
>> implement getPreAuthenticatedPrincipalName.
>> With this refactor the J2eeAuthenticationFilterConfig would
>> extend PreAuthenticatedUserNameFilterConfig: it would be pratically empty,
>> but we could not get rid of it completely since
>> PreAuthenticatedUserNameFilterConfig is abstract.
>>
>> Let me know if this approach is correct for you, and I will proceed with
>> the changes.
>>
>> Regards,
>> Mauro
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Dott. Mauro Bartolomeoli
>> @mauro_bart
>> Senior Software Engineer
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
