Weblogic doesn't cache LDAP
Asked Answered
C

1

6

I have a web application set up using JSF 2.1 and JEE 6 running on a WebLogic 12.1.2 server with an openLDAP for authentication. I've been noticing that loading any page in the app causes multiple BIND requests to LDAP – every single time!

I've read through much of the material and have configured the LDAP provider in Weblogic such that just about any cache I could find is activated. In particular I've set

  • [x] Cache Enabled
  • Cache Size: 10240
  • Cache TTL: 300
  • GUID Attribute: entryUUID

I've also double-checked that the entryUUID attribute exists. I'm not too knowledgable on either WebLogic or LDAP, but I've read just about any page on configuring the cache, but there's still just as many requests to the LDAP (yes, I've restarted the servers after changes.)

I'd appreciate any help, insights or wild guesses as to what may be the cause or how I can debug this issue further. I'm not too sure which config files to attach, but if there's anything needed I'm happy to provide it.

The LDAP requests all look like this:

# journalctl -u slapd
# … many of these …
Sep 16 23:06:03 server.org slapd[15038]: daemon: read active on 13
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND anonymous mech=implicit ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" method=128
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" mech=SIMPLE ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 RESULT tag=97 err=0 text=
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on 1 descriptor
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on:
Caledonian answered 16/9, 2016 at 21:42 Comment(10)
So you have group memberships cached as well as Principal Validator cache? And have you also enabled caches in Security Realms > Providers > Authentication > Performance?Tocsin
@Trent Bartlem Yes, they're all enabled.Andersonandert
Did you check that the application is not re-authenticating the user at each request ?Jetport
Do you have any sort of asserters configured ? How do you take care of SSO ?Avebury
@EmmanuelCollin The web application does a JNDI lookup on each request (which could perhaps be improved), but that's exactly the authentication in LDAP that should be cached, no?Andersonandert
@Avebury We don't use Single Sign-On across applications. We authenticate in the servlet with the credentials and then use them to do JNDI lookups. My expectation is that these LDAP lookups (which we certainly trigger) should be cached by WebLogic.Andersonandert
Weblogic would cache authenticated Subjects if Weblogic container security is place, meaning protecting resources in web.xml and configuring asserter/authenticator in security realm. But if you are having standalone LDAP code to authenticate on which WL doesn't have any control of , you can't expect it to be cached.Avebury
@Avebury That makes sense, but I also rewrote it now such that the JNDI lookup is only done once and then the remote EJB bean is stored in a SessionScoped CDI bean. Even now I still see as many LDAP requests.Andersonandert
@Avebury I've put the JNDI lookup into a SessionScoped bean now where the remote EJB is cached, so there's no more multiple JNDI lookups (also verified with an assertion check.) However, I still see the many LDAP requests, so it doesn't seem to be the JNDI lookup (unless using the EJB requires reauthentication on every remote call?!) But after the point of the JNDI lookup it really feels like caching LDAP would be WebLogic's job.Andersonandert
OK, I think this might be due to the way our application does the JNDI lookup. There seems to be a proxy in between that does the lookup on every method call. That'd be insane. I'll dig deeper into that.Andersonandert
C
1

I have figured out the issue and WebLogic isn't at fault whatsoever. Our application seems to be using a rather broken concept of calling remote EJBs where it creates its own proxy, stores the JNDI information and executes a JNDI lookup on every method invocation.

Therefore, even caching the bean wouldn't help. Of course this bypasses any caching mechanisms and thus results in multiple LDAP binds with every request.

Caledonian answered 19/9, 2016 at 20:11 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.