I think there is a bug in jira where your session times out so you
become anonymous, but you retain your permissions.
-dain
On Aug 7, 2006, at 3:43 PM, Jason Dillon wrote:
Again with anonymous... wtf?!
--jason
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
