tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject JASPIC thoughts and a proposed way forward
Date Fri, 04 Dec 2015 11:42:38 GMT
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


Mime
View raw message