Thanks Les, for your explanation about implementations and interfaces. I see your point of view that you don’t want to force a custom implementation developer to adapt all internal concepts of Shiro. That makes the interfaces clean and easy to understand and use. The login method does essentially two major things: authenticate the user and store somehow his Subject for later use. For my use case I need only the first.
Cibet is kind of Aspect framework but more implementation driven than AspectJ and alike. It allows by fine-grained configuration to control what we call an event, which could be a method invocation, an EJB call, a persistence action on a JPA entity, an http request, JDBC request and so on. Controlling an event means applying some control mechanism which could be security, monitoring, locking, archiving etc. and particularly dual control principles. If an event is controlled by Four-Eyes it is not executed but stored and postponed. Only when a second authenticated user gives his okay (release), the event is executed. Cibet allows also for example to give different permissions for the same method call: The first user has permission to invoke it, but not to release it, the second user has permission to release it. Authentication and Authorization is outside of scope of Cibet, we don’t want to reinvent the wheel. We did already integration with Spring Security (which by the way was much harder to accomplish than integration with Shiro and did cost some more Jira issues) and now with Shiro. The use case where we have this problem is with a special dual control mechanism: Two-Man-Rule <http://en.wikipedia.org/wiki/Two-man_rule> . In addition to Four-Eyes, here the two users must be present at the same time. That means they must both be authenticated and authorized in the same thread/session. A use case could look like this: - A user is logged in in an application and executes something - Cibet detects that this event is controlled by Two-Man-Rule and informs the application that the event is postponed - The application proposes a dialogue to the user for a second login. This must be different to the first one. - Cibet delegates to the security framework (Shiro, Spring Security) to authenticate the second user. Its subject is stored not in the first user’s session but in the Cibet context - Cibet delegates permission check of the second user to the security framework and executes the event if okay. As Cibet is a framework we should not make assumptions on the embedding application. Also we don’t want to force the application developer to make a special Shiro configuration (a special SecurityManager for example) or do a configuration ourselves. In the framework we can make configurations only programmatically. That’s why I prefer to use only the interfaces. I see now only two possibilities: - Split the login method into authentication and storing the Subject in the interface. This is how it is done in Spring Security. However, this would fray out the clean interface and make it more complicated for ‘normal’ users of Shiro. This is not acceptable. - Like I showed in my last email use a CibetSecurityManager which relies on DefaultSecurityManager that does not save the Subject. I can catch ClassCastException and output a big warning, that this method does not work if a custom SecurityManager is used and must be overridden accordingly. best regards Wolfgang -- View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Integration-in-Cibet-framework-tp7577945p7577955.html Sent from the Shiro User mailing list archive at Nabble.com.
