1

I'm looking for some guidelines/tips on how to implement Apache Shiro as a part of a distributed system (client-server) using Java RMI.

I've looked at the answer to this thread : How to organize RMI Client-Server architecture and I'm thinking of using something similar. What I have planned is a remote object (possibly a Singleton?) that handles the authentication when the client log in. If the log in is successful a new session-object is created. But I'm not quite sure where this object would belong and what information to store in it. Should it be passed on to the client or exists as another remote object.

I'm thinking that it should be used as some kind of session facade where each request from the client is being authorized by Shiro. I'm not sure whether it is best (and possible) to give the client a unique token/identifier that Shiro knows about and can authorized based on for each method-invocation, or to create a remote session-facade object that exists for each connection and stores the information about the current user and so forth.

Also I don't know quite how Shiro handles the Subject when used in multi-threaded application and whether either of the mentioned proposals would cause a conflict.

I'm looking forward to hear your thoughts on this - Thanks!

Community
  • 1
  • 1
Matt Immer
  • 327
  • 1
  • 13

1 Answers1

0

As described in my answer to that question, the login object is indeed a singleton, and the session object is indeed another remote object.

I don't see any difference between the two alternatives you mention about authenticating to Shiro. From the point of view of Shiro, the session object is the client.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I think that what confused me was how Shiro handles currentUser (the subject).As far as I can tell the Subject is binded to the Thread and I wanted a little bit more control. What I found out was that I can just store the Subject in the session-object and still get access to Subject.isPermitted, Subject.hasRole etc.). And Wow I did not expect an answer from the author of the idea :) Based on your comment in the other thread I decided to order your buy so hopefully there more useful information in there :) – Matt Immer Dec 07 '13 at 13:55
  • I do however still need to find a better way to check the permissions. Right now I just use something like public Object myMethod(){ if (subject.isPermitted("myAction")){ /.../ } else { throw new UnauthorizedException(); } } But that can get ugly quite quickly when the amount of methods starts to grow. I still haven't found a good design pattern to handle that, but that is probably a whole new question in itself. – Matt Immer Dec 07 '13 at 14:03