8:23 a.m.
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?
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:29 a.m.
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.
8:55 a.m.
On Wed, 2011-06-08 at 09:23 -0400, Bill Burke wrote:
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.
I won't do this, since:
- Editing web.xml is editing the war
- It makes the war non portable, while jboss-web.xml does not affect
this; so any proprietary element should stay in jboss-web.xml.
BTW, jboss-web.xml is not part of the domain model.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
9:03 a.m.
How about at least restoring the behaviour that was present in previous
AS releases to define custom auth-methods?
On 06/08/2011 02:55 PM, Remy Maucherat wrote:
On Wed, 2011-06-08 at 09:23 -0400, Bill Burke wrote:
> 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.
I won't do this, since:
- Editing web.xml is editing the war
- It makes the war non portable, while jboss-web.xml does not affect
this; so any proprietary element should stay in jboss-web.xml.
BTW, jboss-web.xml is not part of the domain model.
9:12 a.m.
On Wed, 2011-06-08 at 15:03 +0100, Darran Lofthouse wrote:
How about at least restoring the behaviour that was present in
previous
AS releases to define custom auth-methods?
I thought about it, but I'd need to add that config to the domain model,
and this is not so cool since they are classnames (and the idea is to
avoid classnames there).
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
9:29 a.m.
On 6/8/11 10:12 AM, Remy Maucherat wrote:
On Wed, 2011-06-08 at 15:03 +0100, Darran Lofthouse wrote:
> How about at least restoring the behaviour that was present in previous
> AS releases to define custom auth-methods?
I thought about it, but I'd need to add that config to the domain model,
and this is not so cool since they are classnames (and the idea is to
avoid classnames there).
I agree that classnames in domain model == bad. Maybe just have JBoss
Web subsystem search for extension files within META-INF/ of jars. The
extension files would have metadata on how to bind a new auth-method. I
think other subsystems in AS7 work similarly.
BTW, I don't get you. You just completely contradicted yourself. In
your reply to me you said "No way, its non-portable". In your reply to
Darren its "I thought about it, but not sure how to do it yet." Maybe I
should ask Darren to email you whenever I have a suggestion.
Finally, what about my idea to delegate more to the security domain?
Like what authentication mechanism to apply, what valves to apply, etc.?
I can see where you'd want one place to be able to modify how a set of
web apps are authenticated.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:24 a.m.
On Wed, 2011-06-08 at 10:29 -0400, Bill Burke wrote:
I agree that classnames in domain model == bad. Maybe just have
JBoss
Web subsystem search for extension files within META-INF/ of jars. The
extension files would have metadata on how to bind a new auth-method. I
think other subsystems in AS7 work similarly.
BTW, I don't get you. You just completely contradicted yourself. In
your reply to me you said "No way, its non-portable". In your reply to
Darren its "I thought about it, but not sure how to do it yet." Maybe I
should ask Darren to email you whenever I have a suggestion.
Your main proposal is to put proprietary things in web.xml (to indicate
the security domain info), and it's not a good idea.
Proprietary config should go either in the domain model, or in the
per-webapp jboss-web.xml.
Since an authenticator is a valve, it can be specified in jboss-web.xml
for any user provided auth method. As a result, I did not bother trying
to fit an authenticator config in the domain model.
Finally, what about my idea to delegate more to the security domain?
Like what authentication mechanism to apply, what valves to apply, etc.?
I can see where you'd want one place to be able to modify how a set of
web apps are authenticated.
Valves can also be added by other subsystems. The security subsystem can
see that SNEPGO has been set as the auth method, and set whatever valve
it needs to implement it.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
5:29 a.m.
On 06/09/2011 11:24 AM, Remy Maucherat wrote:
> Finally, what about my idea to delegate more to the security
domain?
> Like what authentication mechanism to apply, what valves to apply, etc.?
> I can see where you'd want one place to be able to modify how a set of
> web apps are authenticated.
Valves can also be added by other subsystems. The security subsystem can
see that SNEPGO has been set as the auth method, and set whatever valve
it needs to implement it.
I like the sound of that, I may try adding that - that way we don't need
a configuration map and just a check if JBoss Negotiation is available
and the method set to SPNEGO to trigger adding the valve.
5:47 a.m.
On Thu, 2011-06-09 at 11:29 +0100, Darran Lofthouse wrote:
I like the sound of that, I may try adding that - that way we
don't need
a configuration map and just a check if JBoss Negotiation is available
and the method set to SPNEGO to trigger adding the valve.
If you want to look at some code, you can have a look at the
org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA
subsystem.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
5:50 a.m.
On 06/09/2011 11:47 AM, Remy Maucherat wrote:
On Thu, 2011-06-09 at 11:29 +0100, Darran Lofthouse wrote:
> I like the sound of that, I may try adding that - that way we don't need
> a configuration map and just a check if JBoss Negotiation is available
> and the method set to SPNEGO to trigger adding the valve.
If you want to look at some code, you can have a look at the
org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA
subsystem.
Thanks I will take a look
9:51 a.m.
On 6/8/11 9:12 AM, Remy Maucherat wrote:
On Wed, 2011-06-08 at 15:03 +0100, Darran Lofthouse wrote:
> How about at least restoring the behaviour that was present in previous
> AS releases to define custom auth-methods?
I thought about it, but I'd need to add that config to the domain model,
and this is not so cool since they are classnames (and the idea is to
avoid classnames there).
Just a note: the main thing about classnames in the domain config is we
should not be using them to identify the implementations of plug points
that we ourselves ship. If a subsystem allows custom end-user provided
implementations of a plug point, exposing an alternative config
attribute/element that accepts a class name is ok.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
10:42 a.m.
On 6/8/11 9:51 AM, Brian Stansberry wrote:
On 6/8/11 9:12 AM, Remy Maucherat wrote:
> On Wed, 2011-06-08 at 15:03 +0100, Darran Lofthouse wrote:
>> How about at least restoring the behaviour that was present in previous
>> AS releases to define custom auth-methods?
>
> I thought about it, but I'd need to add that config to the domain model,
> and this is not so cool since they are classnames (and the idea is to
> avoid classnames there).
>
Just a note: the main thing about classnames in the domain config is we
should not be using them to identify the implementations of plug points
that we ourselves ship. If a subsystem allows custom end-user provided
implementations of a plug point, exposing an alternative config
attribute/element that accepts a class name is ok.
Note that if you do this you need to also have a module name if the plug
point is to be used as a static module. If the plug point is a
deployable component, then we are better off expressing that via some
kind of deployer.
--
Jason T. Greene
JBoss, a division of Red Hat
4950
days inactive
4951
days old
11 comments
5 participants
participants (5)
-
Bill Burke -
Brian Stansberry -
Darran Lofthouse -
Jason T. Greene -
Remy Maucherat