Please read below Quoting Andrea Aime <andrea.a...@geo-solutions.it>:
> 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 I NEVER planned using a standard session object. I thought about an auth cooky, salted and encrypted with a temporary key or a similar concept. And I never wanted to make OGC services stateful. I would make the following proposal. I will study spring security and will put the focus on integration into geoserver and avoid reinventing the wheel. I think we can end this tread until more detailed information is available. Cheers Christian > > -- > ------------------------------------------------------- > 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 > > ------------------------------------------------------- > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ 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
