9

Newbie question so bear with me...

Currently I have a Grails 2.4.4 app that used spring-security-ldap 2.0.1 to authenticate + authorised users with an OpenLdap server.

The LDAP people are concerned that without caching this app when move to Production might impact the LDAP server's performance. They had recommend looking into using Redis as a app level caching for users, b4 hitting the LDAP server.

I would like to get some directions before I dive into the POC, make sure I start on the right path:

i) I briefly looked into the 'Grails 1 & 2 Plugins' from Grail org, there are a couple of plugins appeared when I searched for Redis... Which one(s) actually are relevant to what I am trying to achieve?

ii) Assume I had integrated Redis caching to my Grails, how/where do I tell spring-security-ldap to look into the Redis cache first, b4 hitting up the Ldap server?

Thanks in advance any info/guide..

alchn
  • 327
  • 1
  • 5
  • 16
  • Oh, forgot to mentioned, preferably we do not want a DB implementation for users persistence, just the LDAP and Redis for caching. – alchn May 02 '18 at 07:39
  • 1
    I don't have enough info to give a full answer but I've used this plugin for Redis with a large amount of success https://grails.org/plugin/redis?skipRedirect=true, as for the custom login, I would think you'd extend grails.plugin.springsecurity.LoginController & override the auth method by checking your redis cache & if not populated call super auth – Mike W May 09 '18 at 06:18

1 Answers1

5

Here are some advices, as you're not looking for ready-to-use solutions:

  • caching any type of authentication is big security failure as hackers will be able to take advantage of this to bypass some rules implemented into your LDAP solution, such as brute force protections (e.g. block account after N bad password)

  • in order to handle the load on LDAP server side, you could adjust the session token expiration (JSESSIONID or JWT, depending on how Spring security has been configured). For example, if token expiration is 1 hour, you will receive only 1 request per hour per user.

  • you could had refresh token mechanism to renew session token without querying LDAP. In this case you will have only 1 LDAP request per device per user, which might be acceptable. Here is how to do it using Grails JWT In this doc you will see that REDDIS can be used to store token, which is quite related to what your initial solution

Benjamin Caure
  • 2,090
  • 20
  • 27
  • Thanks for advices! As the app in concern is not highly sensitive, I might still go on with the manual caching of authentication (Also I am already halfway there... :-\ ) If it happened that a brute force attack on the cache will be a concern, I might be able to manual-roll to block brute attacks. Heck, it sounds like a lot of work already. – alchn May 10 '18 at 06:13
  • But out of curiosity I took a peek at the Spring-Security-Rest plugin documentation http://alvarosanchez.github.io/grails-spring-security-rest/1.5.4/docs/guide/introduction.html. Some questions just to clarify: i) As long as after the first LDAP authentication and token is stored locally & alive, the LDAP server will not be called at all subsequently? ii) How is the token base flow prevent brute attempts (as well as other LDAP rules enforcement), if the LDAP server is not called? – alchn May 10 '18 at 06:16
  • JWT token is protected from brute force because it is encrypted with private key lots more complex than any password policy can be, like session cookie. Here is some discussion about it https://security.stackexchange.com/questions/87119/how-secure-are-expiring-tokens-and-refresh-tokens – Benjamin Caure May 10 '18 at 19:37