Idiosyncrasies of java.security.AccessController

As part of cleaning up Jetspeed 2 JAAS RdbmsPolicy, i ran into some not so obvious idiosyncrasies of java.security.AccessController and the differences between doAs(), doAsPrivileged() and whether to pass the AccessControlContext or not.
On the differences between doAs() and doAsPrivileged(), I found a good post of Sun Java Forums:

doAsPrivileged effectively means you are granting
the calling stack your [code's] privileges when executing the code in question. Whereas doAs only associates the subject with the current access control context, all the calling code still requires the permission to be assigned to it (under the subject in question).

Where it gets interesting, is that when implementing a custom policy, and assessing whether the caller is authorized to access the callee, in implies(ProtectionDomain protectionDomain, Permission permission) the protectionDomain does not contain the principals when performing a doAs check. As mentioned in this post on the Java Forum, when the permission check is concerned about the principals in the subject (call to protectionDomain.getPrincipals()) for the security check, the security check should be performed as:

doAsPrivileged(theSubject, anAction, null)

By passing in a null access control context, the caller is essentially saying: "I don't care who called me, the only important thing is whether I have permission when associated with the given subject".

Subtle differences...

Making Sense of Identity Management

With the rise of service oriented architecture, maintaining a consistent user identity across multiple enterprise systems is becoming increasingly difficult. In an attempt to address the pain that many large IT organizations go through, the software industry has given birth to an onslaught of standards with the purpose of maintaining a common identity across the enterprise. Jason Rouault from HP has written a great paper that sheds some light on that space: Making sense of the federation protocol landscape. As an introductory reading, I strongly recommend An introduction to identity management as well. I like the following definition for identity management:

The set of processes, tools and social contracts surrounding the creation, maintenance, utilization and termination of a digital identity for people or, more generally, for systems and services to enable secure access to an expanding set of systems and applications.

The following pictures sums it up well from a conceptual standpoint:

In my views, a right identity management strategy can provide a strong competitive advantage to an organization as distributed application or services can leverage a much better known user and therefore increasingly build value added to address their employees, customers, partners, and suppliers needs. As organizations consider service oriented architectures, it is critical to craft an identity management strategy in line with such distributed services.

Key Reports for Monitoring Application Development - Need for Historical Data

When managing distributed software development teams with wide ranging skills sets, code base intelligence becomes critical to ensure the quality of the ongoing development effort. Here are some lessons learned worthwhile sharing:

• Unit test code coverage should be put in historical context: Tools like Cobertura and Clover provide great unit test coverage reports; however, most default reports provide point in time coverage and as a result become difficult to use as a metrics for the development effort. To create a successful developer testing practice, developers activities should be measured against specific targets. Setting developers unit testing targets is a great practice to foster the creation and development of unit tests as an implicit and routine part of their activity. Historical measurement is critical to be able to manage such activity efficiently. Clover provides such historical coverage report.
• Unit tests are necessary but beware of bad tests: Enforcing unit test coverage is important to facilitate future development work and improve code quality (see previous post), however poorly written unit tests can provide a fall sense of confidence that proper checks are in place. Unit tests that provide poor assertions checks will result in reasonable code coverage but will not provide the proper checks for guaranteeing the code base quality. In addition to unit test reports, and code coverage reports, unit test code should comply to a specific set of rules as illustrated by the PMD Junit rules.
• Measure your developers activities: Activity reports measuring development activity can provide great insight on the evolution of a code base and the activity level of various contributors. StatCVS provides a very detailed set of statistic that can be useful to understand and monitor the activities of a large and distributed team.
• Dashboard and code quality indexes: Dashboard are critical for management to be able to measure and assess the evolution of various components of a large project. Maven provides a flexible plugin for a point in time dashboard. However, in order to properly follow the evolution of a large development project, historical data is important as it provides the ability to identify key areas of improvement as well as measurable targets. Continuous improvement and continuous refactoring often advocated by agile development methodology advocates requires good metrics to measure improvement and justify the benefits.

Those reports provide a sample set of tools that can be useful when managing development teams. However, one key issue for management is to be able to correlate metrics improvement with critical business metrics such as development effort cost savings (shortened features development time lines, decrease bug level, shortened quality control, etc). More thoughts to come on that subject...