In this post, you'll learn how OACC's latest feature simplifies integrating your application with this powerful open-source Java security framework and removes a coupling concern at the same time.
The Old Way of Doing Things
OACC excels at maintaining complex security relationships between your application entities and at answering any authorization questions about those relationships. Prior to the rc.5 release, every call to OACC's API required identifying your application object via an associated resource id that OACC generated for you when registering the application object you wanted to secure. Consequently, you were responsible for storing the mapping between the generated resource id and your application's native identifier for that secured object.
Resource userResource = oaccContext.createResource("USER", "APP_DOMAIN"); // persist userResource's resourceId in your user model here ... ; // let new user inherit permissions from the user-role oaccContext.setResourcePermission(userResource, userRoleResource, inheritPermission);
Storing an association between an OACC resource and the application object it represents can be classified as coupling, which - even as minimal as it is - still detracts from OACC's goal of isolating your application model from security artifacts. And what do you do when it is just not feasible to extend your application model in such a way?
External Ids to the Rescue
With the v2.0.0-rc.5 release, OACC removes the need to store the generated resource id by introducing an optional external id as an alternative resource identifier. Now you can specify any unique String to reference resources in OACC and thus can avoid mapping identifiers to your application model. Neither will you need to support reverse lookups when OACC returns lists of resources accessible by permission — you can simply use your entities' native identifiers throughout.
// persist your user object here, before creating a corresponding OACC resource User newUser = ... ; // OACC maintains the association to your app's object with the 3rd parameter `externalId` oaccContext.createResource("USER", "APP_DOMAIN", newUser.getId()); // let new user inherit permissions from the user-role Resource userResource = Resources.getInstance(newUser.getId()); oaccContext.setResourcePermission(userResource, userRoleResource, inheritPermission);
Give It a Try
The new method of referencing your secured application objects in OACC by using your native identifiers as external ids - instead of mapping and storing OACC resource ids in your application - is simpler, more convenient, and doesn't introduce unnecessary coupling. This means there's no longer any reason not to give OACC a spin, if you are looking for a permission-based security framework for Java that provides authentication and advanced authorization services.
OACC supports hierarchical security domains, super users, permission inheritance and impersonation. OACC is more powerful than ACL with groups, allows you to model hierarchical symmetric RBAC, and has no container dependencies.
The key design goals of OACC are:
Simplify the maintenance of complex, real world security topologies.
Allow both fine and coarse grained access control.
Support logical security domains for use in multi-tenant application architectures.
Facilitate flexible permission delegation control.
Programmatically and dynamically manage permissions.
OACC is open source software released under the commercial friendly Apache License, Version 2.0.
You can find more information about OACC — including the latest Javadocs, releases, and tutorials — at oaccframework.org.