You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2016/02/09 15:04:24 UTC
JASPIC progress
I've been working with the JASPIC test suite Arjan recommended[1]. There
are a few wrinkles but I've got things working well enough that I can
test the JASPIC code I'm working on.
I've reached the point where I need to hook in to the authenticators and
this had raised some interesting questions.
The samples use a SevletContextListener to register the JASPIC
AuthConfigProvider.
The problem is that SevletContextListener events fire after the
authenticator has been configured.
As I thought about this some more, I realised that there is nothing in
the Servlet Container profile in the JASPIC spec (that I have been able
to find) about when AuthConfigProvider registration takes place. This
means that AuthConfigProvider registrations and de-registrations could
take place while the web application is running.
I am currently leaning towards a refactoring of AuthenticatorBase along
the following lines:
- implement authenticate() and have it delegate to a new protected
method doAuthenticate()
- have authenticate() check (i.e. on every request) for a JASPIC config
and use it if present
- cache what I can (for speed) and use a RegistrationListener to track
updates
The refactoring does mean that any custom authenticator will not support
JASPIC unless it is updated to over-ride doAuthenticate() rather than
authenticate().
I'm concerned that looking for a JASPIC configuration on every request
could slow things down. I'll test this and, if it does, I'll make JASPIC
support something that has to be explicitly enabled for a Context.
Thoughts? Comments?
Mark
[1] https://github.com/javaee-samples/javaee7-samples
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JASPIC progress
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 2/9/16 9:26 AM, Mark Thomas wrote:
> On 09/02/2016 14:18, Rémy Maucherat wrote:
>> 2016-02-09 15:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
>>> Thoughts? Comments?
>>>
>>
>> Thanks for the report. However, the more I thought about it, the
>> more I was convinced JASPIC is useless [besides Arjan asking for
>> it, there's still nobody actually requesting it as a Tomcat
>> feature], so I don't think it is a good idea to introduce
>> complexity or degrade performance to have it. I would go with the
>> last option: require explicit configuration on the Context.
>
> Thanks for the feedback. I share you concerns regarding
> performance.
>
> In terms of demand, no-one is asking for it directly but it does
> provide a way to add SAML support (BZ 54503) and I suspect there is
> demand for OAuth as well.
+1
There isn't a good way to do these kinds of "SSO" interactions unless
the application can be a part of the conversation.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAla5/jwACgkQ9CaO5/Lv0PCL2ACfZO2R/EH6FnIpBjQ85I2vy1yA
G0EAnjPiJPFPgB4tlDFJWW595J8MoG6c
=pom9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JASPIC progress
Posted by Rémy Maucherat <re...@apache.org>.
2016-02-09 15:26 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 09/02/2016 14:18, Rémy Maucherat wrote:
> > 2016-02-09 15:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
> >> Thoughts? Comments?
> >>
> >
> > Thanks for the report. However, the more I thought about it, the more I
> was
> > convinced JASPIC is useless [besides Arjan asking for it, there's still
> > nobody actually requesting it as a Tomcat feature], so I don't think it
> is
> > a good idea to introduce complexity or degrade performance to have it. I
> > would go with the last option: require explicit configuration on the
> > Context.
>
> Thanks for the feedback. I share you concerns regarding performance.
>
> In terms of demand, no-one is asking for it directly but it does provide
> a way to add SAML support (BZ 54503) and I suspect there is demand for
> OAuth as well.
>
> Ok that sound good. In that case since it is relatively specific and not
trivial to setup, so an extra configuration in Tomcat to enable JASPIC
shouldn't be a major issue.
Rémy
Re: JASPIC progress
Posted by Mark Thomas <ma...@apache.org>.
On 09/02/2016 14:18, Rémy Maucherat wrote:
> 2016-02-09 15:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
<snip/>
>> Thoughts? Comments?
>>
>
> Thanks for the report. However, the more I thought about it, the more I was
> convinced JASPIC is useless [besides Arjan asking for it, there's still
> nobody actually requesting it as a Tomcat feature], so I don't think it is
> a good idea to introduce complexity or degrade performance to have it. I
> would go with the last option: require explicit configuration on the
> Context.
Thanks for the feedback. I share you concerns regarding performance.
In terms of demand, no-one is asking for it directly but it does provide
a way to add SAML support (BZ 54503) and I suspect there is demand for
OAuth as well.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JASPIC progress
Posted by Rémy Maucherat <re...@apache.org>.
2016-02-09 15:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
> I've been working with the JASPIC test suite Arjan recommended[1]. There
> are a few wrinkles but I've got things working well enough that I can
> test the JASPIC code I'm working on.
>
> I've reached the point where I need to hook in to the authenticators and
> this had raised some interesting questions.
>
> The samples use a SevletContextListener to register the JASPIC
> AuthConfigProvider.
>
> The problem is that SevletContextListener events fire after the
> authenticator has been configured.
>
> As I thought about this some more, I realised that there is nothing in
> the Servlet Container profile in the JASPIC spec (that I have been able
> to find) about when AuthConfigProvider registration takes place. This
> means that AuthConfigProvider registrations and de-registrations could
> take place while the web application is running.
>
> I am currently leaning towards a refactoring of AuthenticatorBase along
> the following lines:
> - implement authenticate() and have it delegate to a new protected
> method doAuthenticate()
> - have authenticate() check (i.e. on every request) for a JASPIC config
> and use it if present
> - cache what I can (for speed) and use a RegistrationListener to track
> updates
>
> The refactoring does mean that any custom authenticator will not support
> JASPIC unless it is updated to over-ride doAuthenticate() rather than
> authenticate().
>
> I'm concerned that looking for a JASPIC configuration on every request
> could slow things down. I'll test this and, if it does, I'll make JASPIC
> support something that has to be explicitly enabled for a Context.
>
> Thoughts? Comments?
>
Thanks for the report. However, the more I thought about it, the more I was
convinced JASPIC is useless [besides Arjan asking for it, there's still
nobody actually requesting it as a Tomcat feature], so I don't think it is
a good idea to introduce complexity or degrade performance to have it. I
would go with the last option: require explicit configuration on the
Context.
Rémy
>
> Mark
>
>
> [1] https://github.com/javaee-samples/javaee7-samples
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: JASPIC progress
Posted by Mark Thomas <ma...@apache.org>.
On 10/02/2016 14:03, Arjan Tijms wrote:
> Mark Thomas-2 wrote
>> As I thought about this some more, I realised that there is nothing in
>> the Servlet Container profile in the JASPIC spec (that I have been able
>> to find) about when AuthConfigProvider registration takes place. This
>> means that AuthConfigProvider registrations and de-registrations could
>> take place while the web application is running.
>
> It's a good point indeed. In practice it always seems to be either a
> ServletContainerInitializer or a ServletContextListener, or of course via a
> server proprietary method (outside the application).
Thanks for the confirmation.
> I'm not entirely sure what the use case was for having this flexibility.
> I'll try to see if I can get a clarification from Ron about this. I wonder
> how many implementations even support registrations and de-registrations at
> arbitrary moments.
Generally, JASPIC appears to favour flexibility over simplicity. My
first impression is that there is too much flexibility but I am only
looking at it from the fairly narrow scope of a Servlet container.
> Mark Thomas-2 wrote
>> - have authenticate() check (i.e. on every request) for a JASPIC config
>> and use it if present
>> - cache what I can (for speed) and use a RegistrationListener to track
>> updates
>
> That should indeed be the approach.
>
> What the RI roughly does is from its embedded Tomcat in
> AuthenticatorBase#invoke it calls an adapter:
Thanks but I'm not planning on reading the rest as I am concerned about
licensing.
<snip/>
> Hope this helps.
It did. Thanks. It is good to know the code is heading in the right
direction. That some of the javaee7-sample unit tests now pass is alsi
reassuring.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JASPIC progress
Posted by Arjan Tijms <ar...@gmail.com>.
Mark Thomas-2 wrote
> As I thought about this some more, I realised that there is nothing in
> the Servlet Container profile in the JASPIC spec (that I have been able
> to find) about when AuthConfigProvider registration takes place. This
> means that AuthConfigProvider registrations and de-registrations could
> take place while the web application is running.
It's a good point indeed. In practice it always seems to be either a
ServletContainerInitializer or a ServletContextListener, or of course via a
server proprietary method (outside the application).
I'm not entirely sure what the use case was for having this flexibility.
I'll try to see if I can get a clarification from Ron about this. I wonder
how many implementations even support registrations and de-registrations at
arbitrary moments.
Mark Thomas-2 wrote
> - have authenticate() check (i.e. on every request) for a JASPIC config
> and use it if present
> - cache what I can (for speed) and use a RegistrationListener to track
> updates
That should indeed be the approach.
What the RI roughly does is from its embedded Tomcat in
AuthenticatorBase#invoke it calls an adapter:
com.sun.web.security.RealmAdapter#invokeAuthenticateDelegate
That contains code like the following (simplified):
ServerAuthConfig serverAuthConfig = null;
if (helper != null) {
serverAuthConfig = helper.getServerAuthConfig();
}
if (serverAuthConfig != null) {
// JSR 196 is enabled for this application. Call it.
result = validate(request, response, config, authenticator,
calledFromAuthenticate);
} else {
// JSR 196 is not enabled for this application. Use the current
authenticator
result = ((AuthenticatorBase) authenticator).authenticate(request,
response, config);
}
The "helper" variable is set outside the request call, so it functions as a
very quick switch.
getServerAuthConfig() essentially does the following:
AuthConfig authConfig = listener.getConfig();
if (authConfig == null) {
authConfig = factory.getConfigProvider(layer, appCtxt, listener);
listener.setConfig(authConfig);
}
return authConfig;
Where listener and the AuthConfig it holds are just instance variables. One
subtle thing to notice is that when the listener is called to track an
update the config it holds is null'ed instead of actually being updated at
that point.
The actual implementation is a bit more hairy but in broad lines it boils
down to the above, see:
com.sun.enterprise.security.jmac.config.ConfigHelper#getServerAuthConfig
Hope this helps.
Kind regards,
Arjan Tijms
--
View this message in context: http://tomcat.10.x6.nabble.com/JASPIC-progress-tp5046266p5046307.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org