On Mar 28, 2009, at 4:00 PM, Les Hazlewood wrote:
Sure, this is definitely possible, but its probably not necessary.
You can configure multiple realms on the SecurityManager, and any
number of them can participate in an authentication or
authorization operation as desired. An implementation of
org.apache.ki.authc.pam.AuthenticationStrategy dictates how
multiple realms are coordinated during an authentication attempt.
There are a few implementations that exist already and might be
suitable for your needs.
Or you could create your own implementation customize what happens
during an authentication attempt, or even easier, just program your
Realm(s) to react differently depending on some application state
or flag set a runtime. Either way is fine. The Realm-only
approach limits your required knowledge of how Ki works, so I'd
investigate that first.
makes sense - thanks
I will try implementing a "master" Realm that behaves differently
given the application state. It may allow everything, or delegate
to other more complex Realms (LDAP etc)
Hrm. Realms should be thought of as DAOs with a 1:1 correspondence
with a back-end data store. If you have a 'master realm', you start
to blur that line, in which case an AuthenticationStrategy makes
more sense - that is its purpose after all.
But also note that a Realm can elect to not be consulted during
login. If your supports(AuthenticationToken) method on a given
Realm always returns false, it will never be consulted for login,
and instead will be there only for authorization operations.
Or the implementation of that method can change its return value
based on some runtime state: You could make a subclass of
UsernamePasswordToken that wraps the state that trigger certain
login functionality and react to it in the supports(...) method or
other methods. The state of the token (or some other shared state
based on other injected components) could enable your Realm
implementation to react as necessary.
Either of these two points (or both together) might be a better
mechanism for your goals rather than writing a coordinating concept
like an AuthenticationStrategy. But if you feel you must write
coordination logic, you should write an AuthenticationStrategy
implementation.
Ok, I think I understand things now.
Now my only problem is actually sorting out the mechanics of *how* to
change the security manager at runtime. I posted my feable attemts
here:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ki-security/ki-security-examples/ki-security-example-spring-jdbc
It has a button to switch between a "Full Access" account and the
configured JDBC one.
It is not really working, but I would love any guidance on how to make
it work :)
Thanks for all your help!
ryan
Regards,
Les
