Interesting Behavior of isAuthenticated on Jersey + Jetty + Shiro

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

I'm pretty new to Shiro so I wasn't sure if I have done everything correctly.
Here's my scenario:

[Jersey + Jetty + Shiro]

I wrote my code so that if the user is authenticated, there is no need to
login again (just like the one from authentication tutorial). However, what
I'm seeing is that this information may not be shared across threads (I
think that's what happening). Take a look at the print out from the
servletContext log:

2011-03-25 10:22:39.839:INFO:/aan:isRemembered = false
2011-03-25 10:22:39.856:INFO:/aan:login = true
---
2011-03-25 10:22:46.683:INFO:/aan:isRemembered = false
2011-03-25 10:22:46.687:INFO:/aan:login = false
---
2011-03-25 10:22:49.219:INFO:/aan:isRemembered = false
2011-03-25 10:22:49.220:INFO:/aan:login = true
---
2011-03-25 10:22:52.011:INFO:/aan:isRemembered = false
2011-03-25 10:22:52.011:INFO:/aan:login = true
---
2011-03-25 10:22:56.442:INFO:/aan:isRemembered = false
2011-03-25 10:22:56.445:INFO:/aan:login = false
---
2011-03-25 10:22:58.059:INFO:/aan:isRemembered = false
2011-03-25 10:22:58.062:INFO:/aan:login = true
---
2011-03-25 10:22:59.410:INFO:/aan:isRemembered = false
2011-03-25 10:22:59.414:INFO:/aan:login = true
---
2011-03-25 10:23:00.554:INFO:/aan:isRemembered = false
2011-03-25 10:23:00.555:INFO:/aan:login = false
---
2011-03-25 10:23:01.682:INFO:/aan:isRemembered = false
2011-03-25 10:23:01.683:INFO:/aan:login = false
---
2011-03-25 10:23:03.546:INFO:/aan:isRemembered = false
2011-03-25 10:23:03.546:INFO:/aan:login = false
---
2011-03-25 10:23:04.658:INFO:/aan:isRemembered = false
2011-03-25 10:23:04.658:INFO:/aan:login = false
---
2011-03-25 10:23:06.058:INFO:/aan:isRemembered = false
2011-03-25 10:23:06.061:INFO:/aan:login = false

Each pair of isRemembered and login line is basically from the same request.
What I'm seeing here are 2 things:
1) It takes quite a few requests for Shiro to actually understand that user
is authenticated. My assumption is that all threads eventually received the
request and after a while the user is truly authenticated in Shiro.
2) My remember me obviously doesn't work at all since it keeps showing that
the user is not remembered.

My configuration is dead simple and it's pretty much taken from the
tutorial. I have created my own custom realm, which seems to be working fine
(though I have no idea why it has to make 2 separate calls to user
management system, one for doGetAuthenticationInfo and one for
doGetAuthorizationInfo - design flaw?). I believe I'm using native session
since I didn't change any configuration at all. Same goes for the native
cache as well.

[Init code]
Realm realm = new UMRealm();
SecurityManager securityManager = new DefaultSecurityManager(realm);
SecurityUtils.setSecurityManager(securityManager);

[Code for login]
if (!currentUser.isAuthenticated()) {
	UsernamePasswordToken token = new UsernamePasswordToken(username,
password);
	token.setRememberMe(rememberMe);
	currentUser.login(token);
	currentUser.getSession().setTimeout(sessionTimeoutMSec);
}

I know in the tutorial says that I should be doing
SecurityUtils.setSecurityManager(securityManager);, but at this point I'm
not sure what's a better way to initialize the SecurityManager.

Please let me know if anyone has run into the same issue before.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Interesting-Behavior-of-isAuthenticated-on-Jersey-Jetty-Shiro-tp6208130p6208130.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Interesting Behavior of isAuthenticated on Jersey + Jetty + Shiro

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

Just FYI. I did figure out why remember me feature doesn't work on non-web
application. The tutorial basically left out the part that it actually has
to be enabled and also the fact that there isn't actually an implementation
of RememberMeManager for non-web application (there is a
CookieRememberMeManager from web package).

Thought this would be helpful to someone who runs into the same issue.

http://shiro.apache.org/static/current/apidocs/org/apache/shiro/mgt/DefaultSecurityManager.html

As for the multiple logins, I'm still trying to figure out why it's
happening for non-web application (though it looks like we may move away
from using Shiro so don't wait to hear back from me). It seems to be okay
for web application.

Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Interesting-Behavior-of-isAuthenticated-on-Jersey-Jetty-Shiro-tp6208130p6271150.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Interesting Behavior of isAuthenticated on Jersey + Jetty + Shiro

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

Hi Les,

Thanks for the suggestion. I will take a look at it. I guess I should have
been more clear about what I'm trying to do.

Basically, I was being lazy and decided to use Jersey REST service + simple
UI as my test harness since it's quickest way for me. What I was trying to
do is actually testing non-web applications. However, what I will ultimately
end up doing is using Shiro to manage both web app + non-web app. A typical
scenario would be:

UI -> Servlet -> App A -> AppB -> ... (servlet is web tier for App A and App
A sends a request to service provided by App B, etc.)

What would be the best way to have the Shiro session working across web apps
and non-web apps for SSO? I also saw that I should be using
DefaultWebSecurityManager, but when I tried using it, I got this exception
"SessionContext must be an HTTP compatible implementation".

Today is the second day I work with Shiro so I'm still trying to understand
how everything works.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Interesting-Behavior-of-isAuthenticated-on-Jersey-Jetty-Shiro-tp6208130p6209116.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Interesting Behavior of isAuthenticated on Jersey + Jetty + Shiro

[Les Hazlewood <lh...@apache.org>]

Hi Jack,

It doesn't appear that you have configured Shiro for a standard web
environment.  The setup code that you referenced (where you
instantiate a DefaultSecurityManager directly) is really only used for
non-web applications.

Shiro's web support sets up the proper SecurityManager instance and
ensures the Subject is available on the request thread as necessary
for any request.  This will be a big help:

http://shiro.apache.org/web.html

Let us know if that doesn't work for you.

Cheers,

Les

Re: Interesting Behavior of isAuthenticated on Jersey + Jetty + Shiro

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

Just to point out why this is a serious issue. Basically, a user must logged
out multiple times to make sure he/she no longer authenticated. I can of
course setup session timeout so they eventually expire, but I'm looking for
a proper fix.

Any suggestion on where I should begin to look would be great.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Interesting-Behavior-of-isAuthenticated-on-Jersey-Jetty-Shiro-tp6208130p6208358.html
Sent from the Shiro User mailing list archive at Nabble.com.