[jboss-as7-dev] Security Subsystem Configuration Problems

[Jason T. Greene]

On 9/29/11 11:32 AM, Marcus Moyses wrote:
>
>
> On 09/29/2011 01:39 AM, Jason T. Greene wrote:
>> I have been looking into updating the security subsystem to comply
>> properly with the management operation/interaction conventions, notably:
>>
>> 1. All attributes are writable
>> 2. All operations and attributes have complete and correct descriptions
>> 3. Resources are used in preference to custom attributes
>> 4. Reasonable validation is performed
>>
>> I also wanted to fix the plug point for custom login modules.
>>
>> Digging into this though I found that this subsystem isn't complying
>> with the overall Andiamo goal of only exposing things that the user
>> cares about, and is safe to touch.
>>
>> Pretty much all of the previously exiting wiring is exposed in the
>> domain model. So like for example you can change the
>> AuthenicationManager, TrustManager, CallBackHandler, AuditManager, and
>> MappingManager.
>>
>> Do we really want to expose these things? Are customers/users actually
>> using these hooks? If so, is there better alternatives? As an example,
>> if you replace the authentication manager, which is essentially the
>> entire implementation of picketbox authentication, then the remaining
>> configuration of the security domain might not even be handled properly.
> Unfortunately yes, customers do override our implementation in rare
> cases so we need to provide a means for them to do so. From my past
> experience in support we probably just need to allow the
> AuthenticationManager to be overridden. I don't recall any support
> tickets where the other options where replaced by custom code.

Ok good to hear it does have at least some occasional usage. (I couldn't 
find any form posts or mailing list discussions or web pages talking 
about someone doing this) Since it's so rare I think it makes sense to 
make these properties at least for now. IMO, long term, if someone 
really needs to do this level of change they might as well author their 
own security extension.

I think we should reach out to everyone that's done this and find out 
why they needed to do it, and maybe draw cleaner hooks from that 
information.

-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat