geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <...@geronimo.apache.org>
Subject [jira] Updated: (GERONIMO-1563) Make the JACC implementation pluggable
Date Sun, 18 Jun 2006 20:53:31 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-1563?page=all ]

David Jencks updated GERONIMO-1563:
-----------------------------------

    Attachment: GERONIMO-1563-step2.1-v2.diff
                GERONIMO-1563-step2.1-v2-openejb.diff

Here's a version using any + noupa switch in xmlbeans.    Due to the noupa switch it only
compiles using m2.  You may need to apply http://jira.codehaus.org/browse/MXMLBEANS-20 to
your local copy of the m2 xmlbeans plugin to get it to compile, at least offline.  Since there
is no m2 assembly plugin I can't verify that this results in a running server.

I think the basic structure of the NamespaceDrivenBuilder and NamespaceDrivenBuilderCollection
is reasonable and I'll see if I can make it work using substitution groups per gianni's suggestion.

> 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
>
> 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


Mime
View raw message