Hi Mauro
I had a look at your pull request, nice work !
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)
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
- a role service
- a user/group service
- an HTTP header attribute
If we want to open the J2EE filter for 1) we should also allow 2) and 3).
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.
Btw, the GeoServerX509CertificateAuthenticationFilter misses possibility 4), a common base class for those 2 filters may be a solution.
What do you think ?
···
On Tue, Oct 8, 2013 at 7:53 PM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
Hi Christian,
I prepared a pull request for this: https://github.com/geoserver/geoserver/pull/354
Please, review it if you can.
Regards,
Mauro Bartolomeoli
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
2013/10/4 Christian Mueller <christian.mueller@anonymised.com>
Hi Mauro
No, you cannot backport. Lets assume you add a boolean “useRolesFromRoleService” with a default value of false. This is nice because you do not have to add migration code. Lets assume you add “useRolesFromRoleService” in 2.4.1.
An admin using 2.4.1 changes something in the configuration and saves the configuration. The XStream persister saves the xml file including “useRolesFromRoleService”. Afterwards, the admin decides to switch back to 2.4.0. Upon start, you will see a XStream exception because “useRolesFromRoleService” is in the xml config file but not in the class of the configuration object.
As far as I understand the developer guidelines, it must be possible to switch between bug fix versions without migration of the data directory.
Personally, I would like to see your enhancements in the original J2EEAuthenticationFilter on trunk.
Possible solutions for 2.4.x
- As I already mentioned, hack the J2EEAuthenticationFilter directly and replace the class file in the jar file
- Develop you own extension. The security system is designed to allow extensions, the CAS extension is an example. This solutions is more time consuming and it should not be an “official” extension.
Summary:
The problem occurs if
- An admin adds a J2EEAuthenticationFilter on 2.4.x having x > 0
- The admin swtiches back to 2.4.0
The probability of this situations tends to zero but according to Murphys law, it will happen.
Sorry for the bad news
Christian
–
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
On Fri, Oct 4, 2013 at 8:44 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
2013/10/3 Christian Mueller <christian.mueller@anonymised.com3674…>
Hi Mauro
Sorry, my information was not correct. If you add instance vars to a config object, you cannot backport.
Adding instance vars having the Java default value as the GeoServer default value does not require migration code. (boolean → false, int → 0, String → null,…).
Hi Christian, it’s not clear to me if there is any way to add a new flag and allow backporting. My idea was to add a flag (get roles from roleservice) with a default value of false or an int (0=actual behaviour, 1=use only roleservice to get roles, 2= use both). With both options I would have a default value of false or 0, that does not require migration code. Can I backport this changes if I go this way?
Just to be clear, I think my customer would prefer that this enhancement could be included in official 2.4.x versions, and we are too far away from a 2.5.0, so I’m just trying to understand if there is any option to have a backport. Another option coming to my mind is having a completely independent filter very similar to J2EEAuthenticationFilter, maybe even extending it, with this alternative behaviour for fetching roles, but in my opinion it would be preferrable to directly change the original J2EEAuthenticationFilter.
What do you think?
Regards,
Mauro Bartolomeoli
–
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
