[jboss-as7-dev] Security Subsystem Configuration Problems

[Anil Saldhana]

On 09/28/2011 11:39 PM, 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
If there are any gaps in management operations or issues, please
create some JIRA issues. :)
> I also wanted to fix the plug point for custom login modules.
We are using a custom login module ()
for an example deployment on AS7 in OpenShift.
We have configured the fqn of the login module in the domain model and 
the jar containing
the login module sits in the WEB-INF/lib of the web application. There 
is no other configuration.
I am not sure what additional pluggability Bill needs. :)
================
<security-domain name="external_auth" cache-type="default">
<authentication>
<login-module code="org.picketlink.social.auth.ExternalAuthLoginModule" 
flag="required"/>
</authentication>
</security-domain>
=================

> 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.
Agree on the goal.

> 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.
We intend to allow users to change the implementations. Whether
users actually use all of them, is an issue for debate.  Let me check
with support guys to see if we have had instances of users plugging in their
implementations.  These are plug points for solution providers/ISVs.

We can keep the Andiamo goal (you listed above) as the guiding principle
going forward.
> 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.
>
> 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.