Re: [jboss-as7-dev] web security extensions
On 06/08/2011 02:23 PM, Bill Burke wrote:
I think AS7 and JBoss Web needs some cleaner integration if you want
to
define your own web security extensions to do your own custom
authentication for instance.
Right now you have to define in jboss-web.xml:
<jboss-web>
<security-domain>java:/jaas/SPNEGO</security-domain>
<valve>
<class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
</valve>
</jboss-web>
It would be cool if you could replace the<valve> in jboss-web.xml with
an<auth-method> within web.xml. I think I know how this could be done
with no modifications to JBoss-Web, but where would you put the mapping
information? Within JBoss-web's subsystem domain model?
Yes the code to add it back in is simple it is just deciding where it
should live.
There is however a general opinion that class names should not form a
part of the domain model so a mapping of this sort would go against that.
I wonder if it could make sense as subsystems are added to the server
that they also register any authenticators that they provide so a static
definition of the mapping could be eliminated - the same could then
apply to the registration of the actual login modules if that was
handled in a similar way.
Furthermore, I think it would be even cleaner if that type of config was
ditched in favor of a URI within web.xml i.e.
<login-config>
<auth-method>BASIC:/webconsole</auth-method>
...
</login-config>
The above would mean BASIC authentication using the "webconsole"
security-domain. I think it would be interesting also if JBossWeb asked
the security domain for valves it should use/apply.
i.e.
<login-config>
<auth-method>security-domain:/webconsole</auth-method>
...
</login-config>
In this case, JBoss Web sees "security-domain" so it looks up the
"webconsole" security domain and asks it to set up all the appropriate
valves that are needed to set up.
In this manner, multiple web apps could use the same security domain and
you wouldn't have to change their config if you wanted to change the
authentication method. The security domain has complete control over
the authentication mechanism. You could take this even further fully
delegate security constraint application to the security domain. THis
would be very interesting as then an Identity Management service could
have complete control over security metadata without having to modify
the WAR.