geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Date Mon, 07 Aug 2006 22:43:25 GMT
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
>
>


Mime
View raw message