Hi Ryan, Please see in-line below.
I'm trying to get started with JSecurity/Ki and before chasing myself down > the wrong path, i figured I would ask here first.. (BTW, is this the > preferred location? what about http://www.jsecurity.org/forum ?) > The jsecurity.org site is older and should be marked as deprecated now that we're an Apache Incubator project. The forums aren't watched as actively as the mailing lists. jsecurity.org is really only still online for archival purposes only. > I have a wicket application where I need to offer a variety of > authentication methods. By default anyone can do anything, then users could > enable security that will either pull authentication from JDBC or LDAP. > > 1. Is it possible to change the SecurityManager/Realm configuration at > runtime? My plan is to configure a SecurityManager in the init() method, > then potentially change it when users twiddle the settings (via UI). > Although I am running spring, I don't want users to have to configure > spring to change the settings. > 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. > 2. I need to apply authentication rules throughout my applicaiton, BUT by > default let anyone do anything. What is the recommend way to do this? Use > something already built? Implement a SecurityManager? I could make a Realm > with all known permissions, but that seems really brittle *and* it would not > let me use "isAuthenticated()" > I'm assuming you mean 'authorization' rules? i.e. who can do what after they have already logged in (authenticated)? Authorization deals with checking roles and permissions, and the security model in that regard, is entirely up to you. If you wanted anyone by default to do whatever they want, you could always program an AuthorizingRealm subclass's doGetAuthorizationInfo method to return a SimpleAuthorizationInfo object that wraps an org.apache.ki.authz.permission.AllPermission instance. Then, as you restrict user's abilities, you can remove that permission association from their account and specify other permissions (can be string based as well - see the org.apache.ki.authz.permission.WildcardPermission JavaDoc for more). As far as isAuthenticated(), which is entirely orthogonal to any of the authorization methods, it is worth understanding the difference between that and being remembered via 'rememberMe' services. Look at the Subject.isAuthenticated() JavaDoc and the org.apache.ki.authc.RememberMeAuthenticationToken JavaDoc to understand the subtle (yet very important) differences. 3. In the wicket examples [1], I am trying to add some debug info to help > learn/understand what is going on. I added a panel to show the contents of > SecurityUtils.getSecurityManager().getClass() but it looks like that is > not used by default (makes sense). Is there a way to access the current > SecurityManager? > For the most part, you don't want to access the SecurityManager directly, but rather use SecurityUtils.getSubject(). As long as you're using the KiFilter in web.xml, you should always have access to the currently executing Subject via that method. You could access the SecurityManager directly, but this is only really necessary when writing lower-level framework integration code, such as in remoting scenarious and federated security environments. I hope that helps! Please let me know if we could be of any more help. Cheers, Les [1] > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ki-security/ki-security-examples/ >
