David Winslow ha scritto: ... > We use HTTP basic auth for authentication in OWS services, and a 'custom' > (not > really, since it's provided by Acegi) form + cookie system for the admin > page. > These share the roles database (which is used for authorization, but not > sufficient for determining whether or not to deny a request), but use (very) > different rules for determining which roles are required for a request. > Apologies if I'm misusing terms here, I'm pretty green wrt security > discussions.
Hum, no, you're right, I'm mixing two things in authentication myself too. We have three moving parts: - the authentication backend: validates the user credentials, returns the user authorities (roles) - the authentication protocol: the way we get to know the user crendentials (basic authentication, digest, cookies, form) - the authorization mechanism: given a "resource" and a user decides whether he can access to it and how >> Admin console wise, seems like saying unix is not flexible >> enough because admins have to be in the ROOT group. What am I >> missing? ;) > > To be pedantic: admins DON'T have to be in the root group; if you divide the > system into different sections you can assign UNIX groups based on what is > needed (ie, groups for database, webserver, etc.). One concept that Tim > Schaub was discussing when we were talking about REST was to have separate > admin permissions at each level of the hierarchy (this is similar in > principle > to adding 'a' to the ACLs in the current layer security configuration). It > would probably be quite annoying to deal with, and maybe it's more > configurability than it's worth (ie, the number of users who would actually > benefit are not worth the amount of work it would be to do this, or the UI > clutter that would be added). But if we are talking about massive GeoServer > installations then it's probably at least considering supporting allowing > different groups of admins. Ok... that's something that came up when talking about per layer security, that is, the abilitity to have a different admin per namespace (folders and maps, in the new config system ideas), which could be interesting if you have a big install shared by different customers (think ISP). This could be done by adding a new kind of "action", that is, not only read and write, but also admin (or more granular, admin-create, admin-update, admin-delete). Service wise, it seems weird to have someone handling WFS and someone else handling WMS over the same data... can you imagine any real world application of this? >> Here I'm loosing you. The authentication mechanism should be one for >> the whole server imho... do you want the console to use the built in >> mechanism and the services to use a LDAP server instead? In the long >> run I would also love to see the authentication mechanism configurable >> from the user interface, like a drop down listing "built-in", "JAAS", >> "CAS", "LDAP" and so on, but still be used "server wide". > > Okay, it seems that I have been misusing 'authentication mechanism' so far to > refer to ways of getting authentication information from the client, rather > than validating and getting the role list from the credentials provided. It > does seem to make sense to have that database shared across the different > 'zones'. Yep, the authentication backend should be one for the whole install. But I see your point about having a different mechanism per zone. ... > > I had in mind the zones configuration replacing the current setup; if > everything is user configurable then you should never need to mess with > settings in the source code. But nothing terribly concrete thus far. I may > have given the wrong impression by listing this as a GSIP on the wiki > (although it is definitely up for discussion). I understand it user wise, I have a harder time thinking about implementing it still using Acegi. The two items you are listing do replace the authentication protocol setup and the authorization mechanism, so trying to draw a parallel: /config/=org.geoserver.acegi.FormAndCookieAuthenticator,org.geoserver.security.AdminOnlyFilter should replace the current: /**=httpSessionContextIntegrationFilterWithASCTrue,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,consoleExceptionTranslationFilter,filterInvocationInterceptor where httpSessionContextIntegrationFilterWithASCTrue,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,consoleExceptionTranslationFilter (and all the associated beans registered in the context) --> org.geoserver.acegi.FormAndCookieAuthenticator and: filterInvocationInterceptor (and all the beans attached to it) --> org.geoserver.security.AdminOnlyFilter (well, sort of, since filterInvocationInterceptor handles all the paths in fact) This looks like something not trivial to achieve in practice. A GSIP that is positively voted is usually implemented as proposed, it implies having not only the good ideas but also the manpower to turn it into real code. Do we have some significant resources to invest on it? Cheers Andrea ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
