Covering J2EE Security and WebLogic Topics

Dude, Where’s My DefaultAuthorizer?

There are some things in life a guy just takes as given — death, taxes, and the warm, comforting presence of the default security providers in WebLogic.

In WebLogic 9.1, though, the DefaultAuthorizer and DefaultRoleMapper were put out to pasture. Sort of. They’re still available but they’re not quite so default anymore. Instead, they were muscled out of the default realm by the new guys in town, XACMLAuthorizer and XACMLRoleMapper.

XACML stands for eXtensible Access Control Markup Language. Led by OASIS, XACML is a standard access control policy language. From the OASIS XACML FAQ:

Currently, there are many proprietary or application-specific access control policy languages. This means policies cannot be shared across different applications, and provides little incentive to develop good policy composition and auditing tools. … XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, “deny” policies, and dynamic policies–all without requiring changes to the applications that use XACML. Adoption of XACML across vendor and product platforms provides the opportunity for organizations to perform access and access policy audits directly across such systems.

The first sentence applies to the DefaultAuthorizer and DefaultRoleMapper which use a proprietary policy language. The last half of the quote is where we find the promise of the XACML standard.

For the typical WebLogic developer, though, it probably doesn’t matter which policy language is used behind the scenes. But since the new XACML security providers are otherwise equivalent to the ones they replace, it makes sense to use the new ones instead. One day in the future you might be glad that your policies are stored in a standard format for the cross-vendor support it provides.