[jboss-as7-dev] Security Subsystem Configuration Problems

[Marcus Moyses]

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.
> I'd love to get this resolved, but in the meantime I am going to make
> this stuff be properties. That way we can at least avoid having to
> support it forever.
>

-- 
Marcus Moyses
Senior JBoss Core Developer
JBoss by Red Hat