I have a couple simple goal. Enabling security while minimizing overhead of
interaction with a user management system. At this point, it's pretty safe
to assume that no unauthenticated requests are allowed as well. There might
be certain exception cases, but that I can be dealt with later. Performance
really matters for this framework.

To achieve the goal, I'm planning to do:

1) Cache session information into Coherence after first request (which also
login). This is when I want to unbind the thread completely after execution.
2) Use session ID instead of username/password for all subsequent
interaction. Build subject manually using session ID.
3) Invalidate the cache only if there is any change to password.
4) Cache implied permissions (OR of user/group/sub group permission of a
subject/dual subjects).
5) Invalidate permissions when there is any change.
6) Session most likely never expire in most cases. Session is destroyed
through logout command.
7) All requests are proxied through for authentication while each method
requiring authorization explicitly invoke isPermitted().

Interacting with user management system is expensive and is always a
bottleneck, especially if they don't have caching mechanism of its own. It's
not unusual to see 70% performance drop when enabling
authentication/authorization (network overhead, various calculations, etc).
The cache is planned to be as close to the using applications as possible
(possibly on the same machine or at least location).

Because of this, logging in every time simply doesn't work (i.e. calling
user management system). I was told that authentication info will be cached
in Shiro 1.2.0. With the new feature, if grabbing the session is as
expensive as logging in every time against cached authentication info, then
I might as well perform a login every time.

I hope it is clearer about what I'm trying to do. I'm definitely open to
ideas if there are shortfalls to this approach.

Thanks,
Jack

--
View this message in context: 
http://shiro-user.582556.n2.nabble.com/Checking-Session-Timeout-tp6373753p6383065.html
Sent from the Shiro User mailing list archive at Nabble.com.

Reply via email to