JASPIC thoughts and a proposed way forward

[Mark Thomas <ma...@apache.org>]

I've been spending some time looking at the JASPIC implementation that
was started as part of GSoC.

To recap the history to save folks digging through the archives:

- JASPIC provides a standard API for pluggable authentication modules

- The most obvious use case is integration with one of the many
  JASPIC-OAUTH module, e.g. [1]

- A JASPIC implementation was started under GSoC earlier this year but
  the project failed after the student disappeared after the mid-term
  evaluation. [2]

- The student returned later promising to finish the work but that too
  came to nothing. [3]

- The aim of the GSoC project was to provide a JASPIC implementation
  and port the various authentication mechanisms (BASIC, SPNEGO, etc)
  to JASPIC modules.

During my review, I have confirmed that the security concerns I
expressed in [2] were well founded. So far, I have only found one issue
but that is one too many. The DIGEST module does not disable the default
caching of the authenticated Principal in the session which renders the
security benefits of digest over http largely useless. I remain
concerned that the unnecessary refactoring of the authentication code
may have introduced further issues.

While reviewing the current implementation, I have also identified
additional concerns:

- The implementation is extremely hard to follow. Part of that is due
  to the nature of the JASPIC API but part of it is down to the
  implementation and is caused by a combination of factors including
  unclear naming and excessive decomposition - to the detriment of
  clarity and performance
- Quite a few details of the JASPIC requirements have been glossed over

Remy has expressed a general concern [4] regarding complexity and speed.

Currently, I share Remy's general concerns although I do wonder how much
of the current complexity is due to JASPIC and how much is the
implementation.

While the current implementation does have issues, I have found it to be
a useful reference when examining alternative approaches so I do not
want to just delete it.

Given all of the above, I would like to propose the following way forward:

- Create a new jaspic-gsoc branch from the current trunk
- Remove o.a.c.authenticator.jaspic from trunk and associated tests,
  references, etc
- Review the javax.security.auth.message.* implementation and
  address any issues found
- Start a new o.a.c.authenticator.jaspic implementation using the
  jaspic-gsoc branch as a reference. Use a combination of copying
  and re-writing as appropriate.

This new JASPIC implementation would have the following aims:
- follow ALL the requirements set out in JSR-196
- enable web applications to configure JASPIC modules (both Tomcat
  provided and 3rd party modules like [1]) without any additional
  Tomcat configuration
- explore re-implementing the current authentication mechanisms
  using JASPIC
- only replace the current authentication mechanisms with the
  JASPIC alternative if the performance of the JASPIC module is
  comparable

If folks are find this approach agreeable, I'm currently planning to
start on this towards the end of next week.

Mark


[1] https://github.com/trajano/openid-connect
[2] http://markmail.org/message/m6zq7scqaiw4eesf
[3] http://markmail.org/message/wu2ckbkdb7d6sg2c
[4] http://markmail.org/message/yppwgmfjedf3pk6d

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: JASPIC thoughts and a proposed way forward

[Rémy Maucherat <re...@apache.org>]

2015-12-04 14:50 GMT+01:00 Mark Thomas <ma...@apache.org>:

> On 04/12/2015 12:29, Rémy Maucherat wrote:
> > 2015-12-04 12:42 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
> >> The DIGEST module does not disable the default
> >> caching of the authenticated Principal in the session which renders the
> >> security benefits of digest over http largely useless.
> >
> > Apologies for missing it.
>
> No need to apologise. I missed it in the original commit and it wasn't
> until I started down the road of a new implementation and I could
> compare the two that I spotted it.
>
> > This one is problematic IMO since the Tomcat authenticator itself
> shouldn't
> > add implementation details about the module used. So fixing it would be a
> > hack. This is something you can think about for custom modules as well,
> > since there's no way to know if cache should be true or false [= cache
> > could have to default to false for JASPIC as a whole].
>
> The best I came up with was passing in an option to tell the module if
> an explicit caching option was set and using a callback to tell the
> authenticator valve to do the caching. It was all rather clunky.
>
> > As a side note, I would like to add DIGEST is going to be quite useless
> in
> > Tomcat 9 (assuming it was ever useful and used in the first place of
> > course). It could actually be proposed for removal, it is only a SHOULD
> in
> > the Servlet spec.
>
> You know me, always happy to remove obsolete / unnecessary code but what
> makes you say DIGEST is going to be useless in 9.0.x?
>

If it is hard to avoid using SSL with Tomcat 9, I don't see what use it
will have. Besides, I never saw any website using it.

>
> > IMO the focus of the GSoC turned out to be wrong: the project was about
> > redoing the Tomcat auth with JASPIC. The main priority should instead be
> > custom modules, and if it happens to work well, then bundle some modules
> > with Tomcat.
>
> +1. Never the less, the GSoC exercise was a useful learning experience
> despite the way it turned out. A fair amount of the new code should end
> up being re-used in some form.
>

Fair enough.

>
> >> This new JASPIC implementation would have the following aims:
> >> - follow ALL the requirements set out in JSR-196
> >> - enable web applications to configure JASPIC modules (both Tomcat
> >>   provided and 3rd party modules like [1]) without any additional
> >>   Tomcat configuration
> >
> > That's the important item.
>
> Agreed. That is where I want to start. See if I can integrate with one
> of the JASPIC-OAuth modules.
>
> >> If folks are find this approach agreeable, I'm currently planning to
> >> start on this towards the end of next week.
> >
> > Ok.
>
> Great.
>
> Rémy

Re: JASPIC thoughts and a proposed way forward

[Mark Thomas <ma...@apache.org>]

On 04/12/2015 12:29, Rémy Maucherat wrote:
> 2015-12-04 12:42 GMT+01:00 Mark Thomas <ma...@apache.org>:

>> The DIGEST module does not disable the default
>> caching of the authenticated Principal in the session which renders the
>> security benefits of digest over http largely useless.
> 
> Apologies for missing it.

No need to apologise. I missed it in the original commit and it wasn't
until I started down the road of a new implementation and I could
compare the two that I spotted it.

> This one is problematic IMO since the Tomcat authenticator itself shouldn't
> add implementation details about the module used. So fixing it would be a
> hack. This is something you can think about for custom modules as well,
> since there's no way to know if cache should be true or false [= cache
> could have to default to false for JASPIC as a whole].

The best I came up with was passing in an option to tell the module if
an explicit caching option was set and using a callback to tell the
authenticator valve to do the caching. It was all rather clunky.

> As a side note, I would like to add DIGEST is going to be quite useless in
> Tomcat 9 (assuming it was ever useful and used in the first place of
> course). It could actually be proposed for removal, it is only a SHOULD in
> the Servlet spec.

You know me, always happy to remove obsolete / unnecessary code but what
makes you say DIGEST is going to be useless in 9.0.x?

> IMO the focus of the GSoC turned out to be wrong: the project was about
> redoing the Tomcat auth with JASPIC. The main priority should instead be
> custom modules, and if it happens to work well, then bundle some modules
> with Tomcat.

+1. Never the less, the GSoC exercise was a useful learning experience
despite the way it turned out. A fair amount of the new code should end
up being re-used in some form.

>> This new JASPIC implementation would have the following aims:
>> - follow ALL the requirements set out in JSR-196
>> - enable web applications to configure JASPIC modules (both Tomcat
>>   provided and 3rd party modules like [1]) without any additional
>>   Tomcat configuration
> 
> That's the important item.

Agreed. That is where I want to start. See if I can integrate with one
of the JASPIC-OAuth modules.

>> If folks are find this approach agreeable, I'm currently planning to
>> start on this towards the end of next week.
>
> Ok.

Great.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: JASPIC thoughts and a proposed way forward

[Rémy Maucherat <re...@apache.org>]

2015-12-04 12:42 GMT+01:00 Mark Thomas <ma...@apache.org>:

> I've been spending some time looking at the JASPIC implementation that
> was started as part of GSoC.
>
> To recap the history to save folks digging through the archives:
>
> - JASPIC provides a standard API for pluggable authentication modules
>
> - The most obvious use case is integration with one of the many
>   JASPIC-OAUTH module, e.g. [1]
>
> - A JASPIC implementation was started under GSoC earlier this year but
>   the project failed after the student disappeared after the mid-term
>   evaluation. [2]
>
> - The student returned later promising to finish the work but that too
>   came to nothing. [3]
>

Yes ! Me not happy :(

>
> - The aim of the GSoC project was to provide a JASPIC implementation
>   and port the various authentication mechanisms (BASIC, SPNEGO, etc)
>   to JASPIC modules.
>
> During my review, I have confirmed that the security concerns I
> expressed in [2] were well founded. So far, I have only found one issue
> but that is one too many. The DIGEST module does not disable the default
> caching of the authenticated Principal in the session which renders the
> security benefits of digest over http largely useless. I remain
> concerned that the unnecessary refactoring of the authentication code
> may have introduced further issues.
>

Apologies for missing it.

This one is problematic IMO since the Tomcat authenticator itself shouldn't
add implementation details about the module used. So fixing it would be a
hack. This is something you can think about for custom modules as well,
since there's no way to know if cache should be true or false [= cache
could have to default to false for JASPIC as a whole].

As a side note, I would like to add DIGEST is going to be quite useless in
Tomcat 9 (assuming it was ever useful and used in the first place of
course). It could actually be proposed for removal, it is only a SHOULD in
the Servlet spec.

>
> While reviewing the current implementation, I have also identified
> additional concerns:
>
> - The implementation is extremely hard to follow. Part of that is due
>   to the nature of the JASPIC API but part of it is down to the
>   implementation and is caused by a combination of factors including
>   unclear naming and excessive decomposition - to the detriment of
>   clarity and performance
> - Quite a few details of the JASPIC requirements have been glossed over
>

IMO the focus of the GSoC turned out to be wrong: the project was about
redoing the Tomcat auth with JASPIC. The main priority should instead be
custom modules, and if it happens to work well, then bundle some modules
with Tomcat.

>
> Remy has expressed a general concern [4] regarding complexity and speed.
>
> Currently, I share Remy's general concerns although I do wonder how much
> of the current complexity is due to JASPIC and how much is the
> implementation.
>
> While the current implementation does have issues, I have found it to be
> a useful reference when examining alternative approaches so I do not
> want to just delete it.
>
> Given all of the above, I would like to propose the following way forward:
>
> - Create a new jaspic-gsoc branch from the current trunk
> - Remove o.a.c.authenticator.jaspic from trunk and associated tests,
>   references, etc
> - Review the javax.security.auth.message.* implementation and
>   address any issues found
> - Start a new o.a.c.authenticator.jaspic implementation using the
>   jaspic-gsoc branch as a reference. Use a combination of copying
>   and re-writing as appropriate.
>
> This new JASPIC implementation would have the following aims:
> - follow ALL the requirements set out in JSR-196
> - enable web applications to configure JASPIC modules (both Tomcat
>   provided and 3rd party modules like [1]) without any additional
>   Tomcat configuration
>

That's the important item.


> - explore re-implementing the current authentication mechanisms
>   using JASPIC
> - only replace the current authentication mechanisms with the
>   JASPIC alternative if the performance of the JASPIC module is
>   comparable
>
> If folks are find this approach agreeable, I'm currently planning to
> start on this towards the end of next week.
>
> Ok.

Rémy