geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Date Mon, 07 Aug 2006 22:56:37 GMT
Do you think someone created an account and set their name to "Anonymous"?

Thanks,
     Aaron

On 8/7/06, David Jencks <david_jencks@yahoo.com> wrote:
> Does anyone know how it is possible that Anonymous can make changes?
> I'd prefer we knew who is doing what.  Exactly what changed here is
> also not clear to me.... the issue was not closed or resolved
> previously.
>
> thanks
> david jencks
>
> On Aug 7, 2006, at 3:39 PM, Anonymous (JIRA) wrote:
>
> >      [ http://issues.apache.org/jira/browse/GERONIMO-1563?page=all ]
> >
> >
> >
> >
> >> [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
> >
> >
>
>

Mime
View raw message