Currently if you're outside of a servlet container, you must explicitly configure a SecurityManager instance and then set SecurityUtils.setSecurityManager(securityManagerInstance);
I don't particularly like this. The SecurityUtils method comes with decent documentation saying that it is an end-user's last resort when configuring a Ki environment (and it should remain so). So, they should be able to configure the system's security manager in an easier manner. What do you all think about having SecurityUtils.getSubject() lazily create a SecurityManager by looking for a default ki.ini (maybe a ki.yml file in the future) at the root of the classpath? Things were expected to work 'out of the box' before if ki.ini was in your classpath. But the problem before is that we would auto-create a sample realm and that really confused people. I'm not proposing we go back to that model - just that if the file exists at the root of the classpath, then we auto-create a SecurityManager according to that file. We still fail if they don't configure things correctly, it is just a much easier set up: no fiddling with Ki-specific classes imported into your source code for configuration. What do you think? - Les
