geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [jira] Reopened: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
Date Mon, 07 Aug 2006 23:04:38 GMT
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
>>
>>


Mime
View raw message