10:13 a.m.
On 9/29/11 6:39 AM, Anil Saldhana wrote:
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.
To expand on what I think you mean, as others may not have the background:
At the appropriate level in the configuration an element like this would
be allowed:
<extension-properties>
<property name="authentication-manager-class-name"
value="com.foo.OurCustomAM"/>
</extension-properties>
(Note: the module name would need to be provided as well, either via
another property or via some special format of the value attribute.)
The subsystem checks for that and uses it if present. But checking for
that specific property is not a formal part of the management API
contract. We can remove support for it at a later time. It's a "use it
at your own risk" kind of thing.
This approach is a middle ground between 2 alternatives -- seeing that a
particular config is something users are likely to want to configure,
and thus exposing formal config elements for it, or seeing that there is
no supportable use case[1] for something and just eliminating it.
Hopefully for any of these we can choose one of the other alternatives.
I think in practice if people use an extension-property for this kind of
thing it will prove difficult to remove support for it in the future.
[1] "Supportable" meaning "we can provide support", not meaning
"justifiable."
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat