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.
