I'll run with Security Manager if only I can get my policy right

So we know running with a Security Manager enhances security (with performance trade off). However not many applications run with SM. Running with SM degrades performance. In some testing I did, it did so on average by 10%, but it really depends on your application and the code path under test. So this performance hit might cause many applications to not consider running with SM. Another reason is that why you turn up SM you applications don't run properly. The access denied exception can be pretty hard to debug and to gather the set of minimum permissions required to run with SM is a tedious task. OC4J has since 10.1.3.1 provided a tool to solve this second issue. Its called PrintingSecurityManager. This security manager is available as a separate jar and can be used in any application, including ones not tied to OC4J or JEE. Basically this tool records security exception and coverts them into a policy grant(based on JDK's default policy file fomat) that would avoid a given security excetion. Now your job remains to review these grants before your put them in your policy file. See this docfor details.

I am hoping this becomes a tool in your arsenal.

Getting this out before the new year rolls in

Better late than never. I presented a BOF at JavaOne 07 with Jeff Trent. We talked about JavaSE, JavaEE & JACC security. We focussed on Authorization aspects of the security. The idea was to give folks 101 on JavaSE & JavaEE(my fingers want to type J2ee so bad) security and how JACC bridges the gap in the two world. Yup, before JACC the authorization model in JavaSE & JavaEE were so different.
Another pre JACC problem is that in JavaEE world there was no standard way to plug in third party Authorization providers. Each app server supported a different mix(if any). Assuming your app server vendor supports third party Authorization Provider plug in, the moment you switch you app server, that integration went kaput.
JACC solves this problem cleanly and in a portable fashion.

JavaSE, deals with Permission, Protection domain, SM & Access Controller. The JavaEE model dealt with security constraints & method permission elements. Every App server dealt with these in their own way. The JACC spec unified these two. The spec is basically divided in three parts. Provider Configuration, Pollicy Configuration and Policy Decision & Enforcement Contracts. Now I would have named these contracts a little different. e.g App Server, Deployment Tool & Runtime contracts. Or something along the lines. You get the drift?

Read on for the lowdown on the three contracts.

The first contract deals with how and app server will install a jacc provider, what a compliant provider should do etc. (See jsr 115 for normative text)
The second contract introduces new permission objects and sets rules on translating security contraints and method permissions into these new permission objects. The objects are then stored in the jacc provider.
The third contract lays the responsibility for PEP(policy enforcement point). It talks different ways for enforcing authorization.

Now what I haven't seen much of if the use of this feature to integrate with Third Party AuthZ providers. I am hoping a reader could point any such integration. Please feel free to add your comments.