shiro configuration

[Conrad Leonard]

Apologies in advance for a multi-part question...

We have LDAP auth configured with Stardog. This works great but it is clear from both LDAP logs and webconsole performance that *every* request is being passed straight through to the LDAP service for authentication. Also in stardog server log there are zillion of these:

Sep 15, 2015 10:29:47 AM org.apache.shiro.realm.AuthorizingRealm getAuthorizationCacheLazy

INFO: No cache or cacheManager properties have been set.  Authorization cache cannot be obtained.

Can I infer from this that auth caching is not turned on by default, but it is possible to configure Shiro with that?

If yes, would that in fact solve the issue we see with every request going to LDAP?

Finally, how would I configure Shiro with a cache? I've not used it before. Just broad hints/pointers to references would be great.

Thanks,

Conrad.

[Michael Grove]

On Mon, Sep 14, 2015 at 9:41 PM, Conrad Leonard <conrad....@hotmail.com> wrote:

Apologies in advance for a multi-part question...

We have LDAP auth configured with Stardog. This works great but it is clear from both LDAP logs and webconsole performance that *every* request is being passed straight through to the LDAP service for authentication.

Correct.  The server keeps no state wrt to user sessions; each request is auth'ed as it comes in.  The overhead of the approach isn't noticeable with the default scheme since the server has the information for auth local.

 

Also in stardog server log there are zillion of these:

Sep 15, 2015 10:29:47 AM org.apache.shiro.realm.AuthorizingRealm getAuthorizationCacheLazy

INFO: No cache or cacheManager properties have been set.  Authorization cache cannot be obtained.

Can I infer from this that auth caching is not turned on by default, but it is possible to configure Shiro with that? 

If yes, would that in fact solve the issue we see with every request going to LDAP?

Yes.  Authentication caching is not enabled for LDAP.  The reason it is not enabled is there is no clear cache invalidation scheme when we're using LDAP.  When Stardog handles security by itself, it knows when to invalidate cache entries.  For LDAP, it doesn't have that kind of visibility.  And Shiro's only cache is, basically, a SoftHashMap.  So if caching is enabled, and there's no memory pressure to evict entries from the cache, users which no longer exist in LDAP would continue to be authenticated without issue from the cache, which is obviously sub-optimal.

I don't know if a time-based eviction strategy would work in your case, but that seems like the obvious, straightforward way we can address this.  I know there is a way to get unsolicited events over JNDI from an LDAP server, which could also be a possibility, though it's a fairly deployment specific approach.

 

Finally, how would I configure Shiro with a cache? I've not used it before. Just broad hints/pointers to references would be great.

We didn't expose this for LDAP due to the above mentioned issues.  Once there's a reasonable caching strategy, we'll make sure users can configure this as needed.

Cheers,

Mike

 

Thanks,

Conrad.

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Conrad Leonard]

Thanks Mike;

The question about configuring the Shiro cache was based on reading some pretty old posts referring to shiro.ini file; I guess that is no longer used.

Yes a periodic clearing strategy on the simple default Shiro cache would certainly suit our use case. Changes to/removal of credentials on our LDAP service are infrequent. We'd be happy to dial the interval right out to an hour or something because our users are internal and we could handle the potential security lag through people management. But even a fairly aggressive setting like 2 seconds would still be a big win for performance as that would save literally hundreds of Stardog - LDAP round trips when populating e.g. the web console or Empire beans. Perhaps a configuration point 'ldap.cache.interval' or similar that interprets a value of 0 to be no caching at all, with other values being interpreted as milliseconds - then the deployer has complete freedom to choose their own sweet spot between paranoia and performance. Of course the documentation should be clear on consequences of the different configuration settings. 

Can we put in a feature request for this?

I don't think listening to LDAP server is necessary; I agree with you that it would be implementation-specific (and hard to support).

cheers,

Conrad.

[Michael Grove]

On Tue, Sep 15, 2015 at 8:06 PM, Conrad Leonard <conrad....@hotmail.com> wrote:

Thanks Mike;

The question about configuring the Shiro cache was based on reading some pretty old posts referring to shiro.ini file; I guess that is no longer used.

Correct.  We stopped using the .ini files around the 1.0 release if I recall correctly.

 

Yes a periodic clearing strategy on the simple default Shiro cache would certainly suit our use case. Changes to/removal of credentials on our LDAP service are infrequent. We'd be happy to dial the interval right out to an hour or something because our users are internal and we could handle the potential security lag through people management. But even a fairly aggressive setting like 2 seconds would still be a big win for performance as that would save literally hundreds of Stardog - LDAP round trips when populating e.g. the web console or Empire beans. Perhaps a configuration point 'ldap.cache.interval' or similar that interprets a value of 0 to be no caching at all, with other values being interpreted as milliseconds - then the deployer has complete freedom to choose their own sweet spot between paranoia and performance. Of course the documentation should be clear on consequences of the different configuration settings. 

Can we put in a feature request for this?

Absolutely.  The ticket number for this is #2510.

Cheers,

Mike

[Conrad Leonard]

Great, thanks Mike.