geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Date Mon, 07 Aug 2006 22:52:09 GMT
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