You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "David Jencks (JIRA)" <de...@geronimo.apache.org> on 2006/02/01 02:26:33 UTC
[jira] Created: (GERONIMO-1563) Make the JACC implementation
pluggable
Make the JACC implementation pluggable
--------------------------------------
Key: GERONIMO-1563
URL: http://issues.apache.org/jira/browse/GERONIMO-1563
Project: Geronimo
Type: Improvement
Components: security
Versions: 1.1
Reporter: David Jencks
Assigned to: David Jencks
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
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ 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
Posted by "Jeff Genender (JIRA)" <de...@geronimo.apache.org>.
[ 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) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417233 ]
David Jencks commented on GERONIMO-1563:
----------------------------------------
sorry for the delay. Can you be more specific about the problems you find? I regard this as a fairly small feature and think that if we can't make patch review work for something this size we need a different development process. I'm hoping to finish the namespace-driven-builder stuff in the next day or two and provide a possible final patch candidate.
> 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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC
implementation pluggable
Posted by "Matt Hogstrom (JIRA)" <de...@geronimo.apache.org>.
[ 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) Make the JACC implementation
pluggable
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417235 ]
Alan Cabrera commented on GERONIMO-1563:
----------------------------------------
I did a fresh checkout of Geronimo and OpenEJB trunk/openej2 and fed the patches in and got errors.
I also see in your comment that I need to apply MXMLBEANS-20 as well?
> 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
[jira] Commented: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12364883 ]
David Jencks commented on GERONIMO-1563:
----------------------------------------
Step one, make a separate gbean for our proprietary config info:
Sending modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java
Sending modules/jetty/src/test/org/apache/geronimo/jetty/AbstractWebModuleTest.java
Sending modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPolicyConfigurationManager.java
Adding modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPrincipalRoleConfigurationManager.java
Adding modules/security/src/java/org/apache/geronimo/security/jacc/PrincipalRoleMapper.java
Sending modules/tomcat/src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java
Sending modules/tomcat-builder/src/test/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilderTest.java
Transmitting file data .......
Committed revision 374193.
> Make the JACC implementation pluggable
> --------------------------------------
>
> Key: GERONIMO-1563
> URL: http://issues.apache.org/jira/browse/GERONIMO-1563
> Project: Geronimo
> Type: Improvement
> Components: security
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>
> 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
Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Posted by Dain Sundstrom <da...@iq80.com>.
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
>>
>>
Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Posted by Jason Dillon <ja...@planet57.com>.
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
>
>
Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Do you think someone created an account and set their name to "Anonymous"?
Thanks,
Aaron
On 8/7/06, David Jencks <da...@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
> >
> >
>
>
Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Posted by David Jencks <da...@yahoo.com>.
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
>
>
[jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation
pluggable
Posted by "Anonymous (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Commented: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12416681 ]
Alan Cabrera commented on GERONIMO-1563:
----------------------------------------
These patches don't work for me. Do you think that it makes sense to build a sec-plug branch?
> 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
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC
implementation pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ 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
Posted by "Jacek Laskowski (JIRA)" <de...@geronimo.apache.org>.
[ 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
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Updated: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Commented: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417236 ]
Alan Cabrera commented on GERONIMO-1563:
----------------------------------------
BTW, this is not a small trival change that you are proposing.
> 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
[jira] Commented: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12364902 ]
David Jencks commented on GERONIMO-1563:
----------------------------------------
Previous commit missed this file:
Sending modules/security-builder/src/java/org/apache/geronimo/security/deployment/SecurityBuilder.java
Transmitting file data .
Committed revision 374211.
> Make the JACC implementation pluggable
> --------------------------------------
>
> Key: GERONIMO-1563
> URL: http://issues.apache.org/jira/browse/GERONIMO-1563
> Project: Geronimo
> Type: Improvement
> Components: security
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>
> 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] Updated: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=all ]
David Jencks updated GERONIMO-1563:
-----------------------------------
Attachment: GERONIMO-1563-step2.1-v4.diff
GERONIMO-1563-step2.1-v4-openejb.diff
Version that uses substitution groups in the schemas and treats them like anys in the processing code to get around limitations on xmlbeans substitution group handling.
There's a remaining problem with xmlbeans validation that I have temporarily worked around by disabling validation. I'm trying to get more info on what to do from the xmlbeans team.
I'd like this version to get reviewed with an eye towards committing it.
> 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] Updated: (GERONIMO-1563) Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Updated: (GERONIMO-1563) [RTC] Make the JACC implementation
pluggable
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=all ]
David Jencks updated GERONIMO-1563:
-----------------------------------
Summary: [RTC] Make the JACC implementation pluggable (was: Make the JACC implementation pluggable)
> [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