Hi Imre, Yes, much easier :) You should be using the Subject.Builder - introduced in 1.0:
http://incubator.apache.org/shiro/subject.html See the 'Custom Subject Instances' section. It sounds like you will want to do something identical to what Shiro's Spring-specific SecureRemoteInvocationExecutor: https://svn.apache.org/repos/asf/incubator/shiro/trunk/support/spring/src/main/java/org/apache/shiro/spring/remoting/SecureRemoteInvocationExecutor.java You can use that as a model for your XMPP support. The key to that implementation is the use of Subject.Binder and then subject.execute method which does the thread binding/unbinding automatically. Cheers, Les On Tue, Jun 22, 2010 at 2:53 PM, Imre Fazekas <[email protected]> wrote: > Dear Les, > > > Well, i'm supporting applications over XMPP basically, extended with WS and > HTTPS in some cases. I'm afraid the DefaultWebSecurityManager cannot be used > in my case. > Using the SecurityManager i was able to get the Session object retrieved by > sessionID and based on the username and principal stored in the Session, i > could build up the Subject. Is there any simpler or more convenient method > for that? > > > Regards, > > Imre > > ________________________________________ > Feladó: [email protected] [[email protected]], > meghatalmazó: Les Hazlewood [[email protected]] > Küldve: 2010. június 22. 18:05 > Címzett: [email protected] > Tárgy: Re: how to realize multi threaded single sign-on > > The 'sessionMode' property only exists on the DefaultWebSecurityManager > class. If you're using the IniShiroFilter, the default SecurityManager > instance made available in the INI configuration is a > DefaultWebSecurityManager instance. > > Please see this: > > http://incubator.apache.org/shiro/web.html > > I'm assuming you're supporting a web-based application? Or are clients > communicating with servers over a protocol other than HTTP/HTTPS? > > Les > > 2010/6/21 Imre Fazekas <[email protected]<mailto:[email protected]>> > Dear Les, > > > Thank you for your fast reply. > Using native sessionMode i receive this, i'm using 1.1 snapshot: > "Property 'sessionMode' does not exist for object of type > org.apache.shiro.mgt.DefaultSecurityManager." > I haven't found this property in the 1.0 either... :( > > Do you know a best practise how to retrieve the user's Subject object by > the SessionID on the SSO server side? > > > > Best regards, > > Imre > > On 2010.06.21., at 18:22, Les Hazlewood wrote: > > Hi Imre, > > Actually your scenario is probably the easiest to do with Shiro. You can > use the same technique using Shiro's session id and ensuring you use Shiro's > native session management ( and not the servlet container sessions). > > You will need to inject a custom SessionDAO into Shiro's SessionManager. > The SessionDAO will use an enterprise clustered cache of Session instances > (e.g. by using TerraCotta or Coherence or GigaSpaces, etc). You can use the > EnterpriseCacheSessionDAO ( > http://incubator.apache.org/shiro/static/current/apidocs/org/apache/shiro/session/mgt/eis/EnterpriseCacheSessionDAO.html) > implementation. It needs to be injected with a CacheManager that talks to > your clustered cache. > > For example in INI configuration: > > [main] > ... > sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO > sessionDAO.cacheManager = $myClusteredCacheManager > > securityManager.sessionMode = native > securityManager.sessionManager.sessionDAO = $sessionDAO > # it is also recommended to use this cache manager for > # other Shiro caching as well: > securityManager.cacheManager = $myClusteredCacheManager > ... > > Then, each time an http request comes in with a session ID cookie, that id > will be resolved by the sessionDAO, which talks to your clustered cache to > retrieve the corresponding persisted Session. Any request can come in on > any of your web servers, and they will be able to 'see' the same session > because of the nature of a distributed clustered cache. > > HTH, > > Les > > 2010/6/21 Imre Fazekas <[email protected]<mailto:[email protected]>> > Dear All, > > > I'm rookie now, just began working with Shiro. :) > SSO functionality is needed in a multithreaded environment meaning > different application server instances. In our home-made SSO, the result of > the user's authentication was a sessionID brought with every request that > the client initiated. This means, that the user may call different services > on different places, the SSO knew if the user has authenticated him/herself > and was able to get the caller subject. > > How can i achieve such functionality in Shiro? The manual thread binding is > a little different thing i guess... > > Thank you in advance! > > > Best regards, > > Imre > > Imre Fazekas > Ygomi Kft. > 4034 Debrecen, Vágóhíd u. 2. > Office: +36 52 887 500 / 8789 > Cell: +36-70-514 8550 > Fax: +36 52 887 505 > Email: [email protected]<mailto:[email protected]> > > > > > > > > Imre Fazekas > Ygomi Kft. > 4034 Debrecen, Vágóhíd u. 2. > Office: +36 52 887 500 / 8789 > Cell: +36-70-514 8550 > Fax: +36 52 887 505 > Email: [email protected]<mailto:[email protected]> > > > > > > >
