Hi Wolfgang, Could you please elaborate your particular use case and the expected behavior? Also, how it may or may not apply to requests and/or threads?
If we understand this better, we can suggest an implementation technique that might be ideal for your requirements. As to your comments about interfaces vs implementations, Shiro's interfaces represent only what _must_ be supported for any given implementation, not what could be supported. This provides us (and Shiro users) the most flexibility possible and is what allows Shiro to be so adaptable to any runtime environment. Configuration necessarily reflects implementation-specific concepts, so you can configure objects (or nested objects) based on your knowledge of the implementation (i.e. not all implementations *should* support a setFoo(...) method, so it is purposefully not defined in the interface). That your current SecurityManager implementation is different than Shiro's default implementation is not a bad thing at all - we try _very_ hard to ensure that components only interact with interfaces where possible so we _don't_ have tight coupling to implementations. You should be able to swap out almost any part of Shiro's SecurityManager object graph without problems. To corroborate this, there are only 2 locations in the entire Shiro codebase (that are not test cases) that explicitly reference the DefaultSecurityManager implementation: The IniSecurityManagerFactory.createDefaultInstance() (which can be overridden for custom implementations if desired). and the Guice integration module's ShiroModule.bindSecurityManager (which can also be easily overridden). You can also redefine the SecurityManager implementation in the ini config's [main] section easily without overriding anything: securityManager = com.foo.my.SecurityManager it's just that most people don't need to do this. So, Shiro was designed explicitly to support your current behavior. However, if you don't want to override the DefaultSecurityManager implementation, please elaborate your use case (multi Subject stuff) and we can see if there is an easier way to solve that problem. Best regards, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk On Thu, Nov 15, 2012 at 9:26 AM, Wolfgang Winter <[email protected]>wrote: > Hi, > > for the next release of Cibet control framework (www.logitags.com/cibet) > we > add integration with Shiro. Cibet allows amongst others dual control > mechanisms like Four-Eyes or Two-Man-Rule. The last one imposes that two > users are authenticated and authorized at the same time. That means while > the first user is logged in a second user must login and his permissions > checked. The Subject of the second user must not overwrite the Subject of > the first user in the session. Shiro allows this by implementing a > SessionStorageEvaluator which decides on a per-Subject basis if to store in > the session or not. > > However, while this approach is perfect for application developers, it is > not when developing a framework like Cibet. The problem is that for > configuring an own SessionStorageEvaluator implementation I must make > assumptions about the configuration of the embedding application. This is > because configuration is possible only over the implementations, not the > Shiro interfaces: > > A programmatic configuration equivalent to > securityManager.subjectDAO.sessionStorageEvaluator = > $sessionStorageEvaluator > implies that > - DefaultSecurityManager is used > - DefaultSubjectDAO is used > > because methods getSubjectDAO() and setSessionStorageEvaluator() are not > exposed in the interfaces but only in the implementations. Furthermore I > have to mark the Subject of the second user somehow to let my > SessionStorageEvaluator implementation decide to not store this one in the > session. However, Subject class and even DefaultSubject have no suitable > methods to mark and even then I fear I have to make assumptions about which > implementation is used. > > My actual solution is to subclass the DefaultSecurityManager and overwrite > save(Subject subject) with an empty method. I use this CibetSecurityManager > for the second login like this: > > public void logonSecondUser(AuthenticationToken auth) { > DefaultSecurityManager utilsSecMan = (DefaultSecurityManager) > SecurityUtils > .getSecurityManager(); > > SecurityManager secMan = new > CibetSecurityManager(utilsSecMan.getRealms()); > Subject subject = new Subject.Builder(secMan).sessionCreationEnabled( > false).buildSubject(); > subject.login(auth); > ... > > This solution seems slightly better because the only assumption here is > that > DefaultSecurityManager is used. However, if someone configures a custom > SecurityManager he will get a ClassCastException. > > Why are the setter methods that are implicitly used in the ini > configuration > not exposed in the interfaces but only in the implementations? For an > application developer this is okay, because he knows what he configures but > as a framework developer I want only deal with interfaces. > > Or does anyone has a better solution for this issue? > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Shiro-Integration-in-Cibet-framework-tp7577945.html > Sent from the Shiro User mailing list archive at Nabble.com. >
