[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12427010 ] Jeff Genender commented on GERONIMO-1563: - +1...same comment as Matt Hogstrom. [RTC] Make the JACC implementation pluggable Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.2 Reporter: David Jencks Assigned To: 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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12426835 ] Matt Hogstrom commented on GERONIMO-1563: - David, I understand what you are doing and agree. Given the magnitude of the change I wasn't able to test it but I am comfortable integrating it. +1 [RTC] Make the JACC implementation pluggable Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.2 Reporter: David Jencks Assigned To: 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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12419216 ] Jacek Laskowski commented on GERONIMO-1563: --- I wonder how the branch might help us since we'll need a patch for the change before it's applied to trunk. If we're not able to create it now, how would it be easier then? [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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12419222 ] David Jencks commented on GERONIMO-1563: I created the branch at the request of alan, who could not apply the patch. It has recently become painfully apparent that many patches produced by svn cannot by applied by patch. While this sort of points out that RTC isn't going to work, we might be able to sidestep this technical problem by creating branches instead of patches. Theoretically svn merge ought to work better than patch since all resources are under control of svn. However, I look forward to endless struggles to apply the simplest patches or merge hundreds of branches. [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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12419291 ] Gianny Damour commented on GERONIMO-1563: - I reviewed this patch; understand its implications; and vote +1. [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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ 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
