[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12419035 ]
David Jencks commented on GERONIMO-1563: ---------------------------------------- Apparently the patches don't apply cleanly. I've created a branch with (hopefully only) this work. To get it svn co https://svn.apache.org/repos/asf/geronimo/branches/pluggable-jacc maven -o m:co which should check out the corresponding openejb branch. I haven't had time to check that this actually works.... will do that soon. > [RTC] Make the JACC implementation pluggable > -------------------------------------------- > > Key: GERONIMO-1563 > URL: http://issues.apache.org/jira/browse/GERONIMO-1563 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: security > Versions: 1.2 > Reporter: David Jencks > Assignee: David Jencks > Attachments: GERONIMO-1563-step2.1-v1-openejb.diff, > GERONIMO-1563-step2.1-v1.diff, GERONIMO-1563-step2.1-v2-openejb.diff, > GERONIMO-1563-step2.1-v2.diff, GERONIMO-1563-step2.1-v4-openejb.diff, > GERONIMO-1563-step2.1-v4.diff > > Currently we are hardcoded into using our JACC implementation. This means we > can't use third party authorization/security servers such as Tivoli AM. > The runtime hardcoding is that the installation of the spec permissions into > the policy configuration is mixed in with pushing our proprietary > principal-role mapping into the policy configuration. > The build time hardcoding is that the only proprietary security configuration > we accept is our own xml for principal-role mapping, and we insist on it > being present. > Some steps for this: > 1. make separate gbeans for the spec and proprietary access to the policy > configuration. These should be connected by an interface, and the spec gbean > should control the proprietary gbean and pass it the contextIds in the > current application. > 2. The security builder should be partly namespace driven, with the > proprietary xml interpretation driven by the namespace. > 2.a the base security builder should construct the > ApplicationPolicyConfigurationGBean and hand off to the namespace-selected > gbean for the proprietary stuff. > 2.b the proprietary-xml builder should install the "role-mapper" gbean with > the info needed for e.g. principal-role mapping. > When we're done with this we should be able to support e.g. IBM pluggable > JACC implementations that support their role-mapping capabilities by just > writing an xml format and a gbean that pushes role mapping info into their > interfaces. The ibm interfaces are explained here: > http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html > If anyone knows how other app servers configure the non-spec part of JACC > references would be very much appreciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
