[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=all ]
David Jencks updated GERONIMO-1563:
-----------------------------------
Attachment: GERONIMO-1563-step2.1-v1.diff
GERONIMO-1563-step2.1-v1-openejb.diff
The attached patches start the process of making the security builder pluggable
by turning SecurityBuilder into a gbean implementing a SecurityBuilder
interface and moving stuff around so everything still compiles.
Next steps are to make the selection of the security builder namespace driven
and to re-examine the SecurityBuilder interface, in particular the default
principal builder used by the TSSEditor.
> 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
>
> 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
