[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12364883 ]
David Jencks commented on GERONIMO-1563: ---------------------------------------- Step one, make a separate gbean for our proprietary config info: Sending modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java Sending modules/jetty/src/test/org/apache/geronimo/jetty/AbstractWebModuleTest.java Sending modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPolicyConfigurationManager.java Adding modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPrincipalRoleConfigurationManager.java Adding modules/security/src/java/org/apache/geronimo/security/jacc/PrincipalRoleMapper.java Sending modules/tomcat/src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java Sending modules/tomcat-builder/src/test/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilderTest.java Transmitting file data ....... Committed revision 374193. > Make the JACC implementation pluggable > -------------------------------------- > > Key: GERONIMO-1563 > URL: http://issues.apache.org/jira/browse/GERONIMO-1563 > Project: Geronimo > Type: Improvement > Components: security > Versions: 1.1 > Reporter: David Jencks > Assignee: David Jencks > > 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
