From: mholzner <nu...@jb...> - 2005-07-27 18:27:38
|
here is the short of it: 1) requirements and goals: * JACC implementations need to be pluggable similar to JAAS modules * JACC modules need to be configurable per application * the current JACC implementation needs to be extended to allow other then J2EE resources to check access control through the same mechanism (portal resources for instance) * the JACC module should allow for more dynamic features , such as access check for portal pages that were created after the portal was deployed * all JEMS components need to use a unified way to check access control (through JACC; to allow easy configuration of a single PDP) * static role assignment (in the login module) imposes too many restrictions (think: user is in role 'bookkeeper' from 9 to 5 only). As a result, for more advanced security scenarios, the JACC provider needs to be the one that handles role memberships (dynamically) 2) implementation details: * JACC modules can be written against a defined API (SPI) that would need to be created * JACC modules can be configured per application (login?config.xml ?) * JACC modules could potentially be stackable ((static)J2EE module, Portal module, jBPM module, custom module...) similar to (but far more flexible then) DelegatingPolicy * container code (interceptors) checks access via an abstracted API very simplified: | Security.implies(permission type, subject, resource, action) | where permission type is one of J2EE, Portal, .... * deployers can discover the configured JACC module and add the correct permissions * all permission types extend java.security.Permission * the abstracted API news up the correct Permission class (based on the permission type) and calls into a deeper layer * this deeper layer reads the configured JACC module(s), loads them, and performs the access check with them * the JAAS and JACC modules need to share some state to allow the JACC provider to get to SAML assertions etc. This would potentially be done via special principals in the subject * if no JACC provider is configured for an app, the JBoss default one is used 3) questions and food for thought: * during our discussion around this topic we realized that most applications up the stack (Portal, BPM, WSRP, ...) all need to handle "identity as data" as well. Meaning: they all need to access user attributes in one form or another. We believe that this topic needs to be considered as well when we try to solve JAAS, JACC , RBAC , SAML,... in this layer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886900#3886900 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886900 |