Authorization Cache Removed when Logged Out

[juminoz <ju...@hotmail.com>]

[Version: Shiro 1.1.0]
[Cache: Coherence 3.7.1]

Is this an intended affect? I would have thought that the information just
stays in the cache so that it doesn't have to go to the source again unless
the cache is invalidated.

Basically, I have a scenario where multiple clients will login using the
same username/password (think DB user). The permission is currently used to
manage collections of data so user can access data it's permitted to. Let's
say if a client logged out, the information is gone from the cache. This
means that other client using the same username will have to fetch the data
from the source again.

Is there currently a configuration to check if there are sessions with the
same username left before wiping out the cache? Or maybe simply disable
removal of user permission from the cache until revalidated.

Also, it seems that Shiro doesn't cache AuthenticationInfo object. Is there
a way to configure it to do so? Authentication is mainly done at connection
time (i.e. client connecting to service provider), but it maybe useful to
actually cache the information as well. A scenario for this is user
impersonation. Even a client can be authenticated at connection time, it may
have to impersonate a user (maybe another client) that is invoking an
operation. This means that each request has to be authenticated again (think
web service with authentication token in the SOAP header).
Authentication/Authorization will then become a bottleneck if it has to go
back to the source every time.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-tp6360724p6360724.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Authorization Cache Removed when Logged Out

[Brian Demers <br...@gmail.com>]

On Fri, May 13, 2011 at 6:10 PM, juminoz <ju...@hotmail.com> wrote:

> So you basically never logout and just let the session expires? I actually
> just found out that my session never actually expires even with timeout for
> some reasons while I was testing to see if permission info is cleared from
> the cache. Or is the user still authenticated even when the session has
> already expired? I tested with
> SecurityUtils.getSubject().isAuthenticated();
> and I get true even after the session is supposed to be expired.
>
> Anyway, back to the topic.
>
> Is there any drawback to keeping session around? Let's say in the case
> where
> a client is impersonating users, there can potentially be 10k+ users (maybe
> 1m+ if you talk about Facebook-liked service). This means that there will
> be
> quite a bit of open sessions.
>

You should be able to use the EnterpriseCacheSessionDAO for 10k users. If
its backed by ehcache, you should be fine,  I am not sure what it scales
too.


>
> My original plan was to logout in the following cases:
> - Client disconnect -> should log user from a particular host out only.
> Other client using the same user stays logged in until disconnect.
> - Logout after completion of impersonation. Basically, log user out when
> user log out from the client side. I actually still need to figure out how
> to intersect client app and user permissions to figure out final set of
> permissions. For example, client application may have access to view any
> user, but the user logging in to the client may only have access to view
> own
> profile only.
>
> Do you see any issue with this approach? Security is definitely not my
> strong point so I'm still trying to figure out the best approach. The key
> to
> my problem is that multiple clients can potentially be using the same
> username. This means that I definitely need to use hostname to
> differentiate
> between them. A user may already be authenticated for a client, but if
> another client is trying to connect, it still has to be authenticated
> again.
> So even though authentication is done separately, they all should share the
> same authorization info since username is the common key.
>

I see your point.  though hostname may not work.  For example I could have
two sessions open from the same host.  It seems the authc/authz cache should
be tied to the session.

Can anyone think of a downside to that?


>
> Also, when is Shiro 1.2 going to be available?
>
> Thanks,
> Jack
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-tp6360724p6361445.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Authorization Cache Removed when Logged Out

[juminoz <ju...@hotmail.com>]

So you basically never logout and just let the session expires? I actually
just found out that my session never actually expires even with timeout for
some reasons while I was testing to see if permission info is cleared from
the cache. Or is the user still authenticated even when the session has
already expired? I tested with SecurityUtils.getSubject().isAuthenticated();
and I get true even after the session is supposed to be expired.

Anyway, back to the topic.

Is there any drawback to keeping session around? Let's say in the case where
a client is impersonating users, there can potentially be 10k+ users (maybe
1m+ if you talk about Facebook-liked service). This means that there will be
quite a bit of open sessions.

My original plan was to logout in the following cases:
- Client disconnect -> should log user from a particular host out only.
Other client using the same user stays logged in until disconnect.
- Logout after completion of impersonation. Basically, log user out when
user log out from the client side. I actually still need to figure out how
to intersect client app and user permissions to figure out final set of
permissions. For example, client application may have access to view any
user, but the user logging in to the client may only have access to view own
profile only.

Do you see any issue with this approach? Security is definitely not my
strong point so I'm still trying to figure out the best approach. The key to
my problem is that multiple clients can potentially be using the same
username. This means that I definitely need to use hostname to differentiate
between them. A user may already be authenticated for a client, but if
another client is trying to connect, it still has to be authenticated again.
So even though authentication is done separately, they all should share the
same authorization info since username is the common key.

Also, when is Shiro 1.2 going to be available?

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-tp6360724p6361445.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Authorization Cache Removed when Logged Out

[Brian Demers <br...@gmail.com>]

Authentication Caching will be in 1.2 (its already in the trunk).

As for clearing the cache on logout, I ran into this the other day.  I was
logging clients out programmatically, which I realized was bad for a bunch
of reasons (for example the client still thinks they are authenticated)

Why are you logging users out?  Instead of just keeping the session around ?



On Fri, May 13, 2011 at 3:26 PM, juminoz <ju...@hotmail.com> wrote:

> [Version: Shiro 1.1.0]
> [Cache: Coherence 3.7.1]
>
> Is this an intended affect? I would have thought that the information just
> stays in the cache so that it doesn't have to go to the source again unless
> the cache is invalidated.
>
> Basically, I have a scenario where multiple clients will login using the
> same username/password (think DB user). The permission is currently used to
> manage collections of data so user can access data it's permitted to. Let's
> say if a client logged out, the information is gone from the cache. This
> means that other client using the same username will have to fetch the data
> from the source again.
>
> Is there currently a configuration to check if there are sessions with the
> same username left before wiping out the cache? Or maybe simply disable
> removal of user permission from the cache until revalidated.
>
> Also, it seems that Shiro doesn't cache AuthenticationInfo object. Is there
> a way to configure it to do so? Authentication is mainly done at connection
> time (i.e. client connecting to service provider), but it maybe useful to
> actually cache the information as well. A scenario for this is user
> impersonation. Even a client can be authenticated at connection time, it
> may
> have to impersonate a user (maybe another client) that is invoking an
> operation. This means that each request has to be authenticated again
> (think
> web service with authentication token in the SOAP header).
> Authentication/Authorization will then become a bottleneck if it has to go
> back to the source every time.
>
> Thanks,
> Jack
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-tp6360724p6360724.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>