On Sat, Mar 26, 2011 at 4:17 PM, <christian.muel...@nvoe.at> wrote: > What you are describing here would work, but this is the "poor man solution" > with many disadvantages. Let us assume a cluster with 32 nodes. > > a) In the worst case, you have 32 individual authentication processes. The > geoserver authentication is not very expensive, but if you think on our > future work about spring security, authentication itself can involve access > to a db or a ldap server or other actions. Normally, on authentication for a > role based access control, the following steps are necessary (at minimum). > > - check the secret > - search for the groups the user belongs to > - calculate the roles as union from user and group roles > - create a session and attach this user profile
The last step is problematic, OGC services are stateless, you never create a session for the user. The current setup does not, a session is created only if you're using the admin interface. See how the spring security is configured for OGC services urls, if there is a session and an auth in it, it will be used, otherwise none will be created. The rest of the arguments based on the presence of a sessionfall as well. A setup made for scalability avoids sessions. >From my experience a solution requiring session is indeed the poorly architected one, not the other way around. There are performance issues if you have to repeat all the auth steps every time, but they can be addressed by caching, user rights do not normally change fast, so a distributed second level cache is going to address the performance problem without having to introduce sessions, which are a problem themselves. This setup is also recognized by Spring security, from the Spring security feature list (http://static.springsource.org/spring-security/site/features.html): "Caching: Spring Security optionally integrates with Spring's Ehcache factory. This flexibility means your database (or other authentication repository) is not repeatedly queried for authentication information when using Spring Security with stateless applications." Forcing OGC protocols to become stateful seems like trying to fit a square peg in a round hole to me. It can certainly be an option, but cannot be the rule. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
