Announcement Announcement Module
No announcement yet.
How to move authentication/authorization management from session to a database? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to move authentication/authorization management from session to a database?


    I'm writing an application aimed at the amazon ec2 environment. As a design principle, I'm avoiding the use of http session in my backend. Actually, at this moment the unique information holded in the http session in my backend is the authentication/authorization data from spring security.

    Since coordinated sessions are still not possible in amazon, and I would like to avoid sticky sessions and still be able to scale up and down transparently to my customers, I was wondering if is it possible to make spring security use a relational database for managing all the users' authentication/authorization data. I know this is much slower than using a local http session, but it's just a first easy implementation. A second attempt will be using the amazon ElastiCache service, which is still slower than a local http session, but much faster than accessing amazon RDS.

    I tried to implement a custom SecurityContextRepository, but it seems that this is not the right place where I should be implementing this switching. I mean, looking at this interface I only see methods that store and query context data, but never removes them.

    Well, that's it. How can I completely change the authentication/authorization management from http sessions to a relational database?

  • #2
    Since HttpSession is an interface, it is typically easiest to work with the other implementations of HttpSession provided by your container. For example, Jetty offers a pluggable session manager that provides NoSQL datastores out of the box (many other containers offer similar such concepts). This approach is recommended for most instances since should require not coding for you and there are likely other reasons you will be using HttpSession (i.e. Spring Flash Attributes to support Post Redirect Get pattern).

    If you do not want to swap out the HttpSession implementation (recommended for most cases), you can swap how the SecurityContext is persisted using the SecurityContextRepository. Keep in mind that SecurityContextRepository will be invoked for every request so you will want to ensure your custom implementation performs well. The SecurityContext will be removed when saveContext is invoked and the SecurityContext represents an anonymous user (i.e. Authentication is null or authenticationTrustResolver.isAnonymous(Authentica tion) returns true).


    • #3
      Implementing a custom SecurityContextRepository is the first step next you probably need a custom LogoutHandler also which, on logout, removes the information from your datastore.

      But as Rob already pointed out you might be better of using a different implementation/store provided by your container (Tomcat has pluggable strategies for storing session information) and use the default HttpSession implementation provided by Spring Security.


      • #4
        Rob and Marten, thanks for the assistance!

        After your comments and googling a bit more, I think that a better alternative would be create a custom AMI where tomcat is configured for using memcached-session-manager for session management. Memcached-session-manager can be configured to work with amazon's ElastiCache service through a client provided by amazon itself. Despite shared sessions are not supported in AWS out of the box, maybe this is the closer I can get from a cluster wide session management. This will cost me some good ours of work since this is my very first experience with AWS services, but, as you pointed out, probably this is the level where the solution should be applied.

        Thank you guys.

        OFF-TOPIC: Conceptually speaking, implementing out of the box global session management for java applications doesn't smell like a very challenging task considering the current AWS services. So, it's interesting to think about why this could not be done yet. I'm sure the demand for this exists and is potentially huge...


        • #5
          I am facing same choices here. Our app supposed to be in Azure cloud though it's J2EE application using spring security 3.2.
          Not knowing what type of plug-gable session management will be available under which application server in Azure, and rapid elasticity is a requirement. We are keen to have our own memcached based user authentication/authorization management. memcached server will be hosted within the cloud and will have auto fail over replication.

          I am writing custom SecurityContextRepository to manage memchached based repository using ssm-1.4.

          We have little more complexity added to it. We need both cookie based as well as http header based authentication. We are providing REST services from the same environment, if a browser accessing the rest services it can be cookie based authentication token after login. If any other app (iOS / Android or any standalone application) then we need to access http header based auth token.

          Did anyone face with similar choices? Have any advice on better implementation for the above scenario?

          Thanks in advance