The token renewal service (TRS) has been used at SLAC National Accelerator
Laboratory since the late 1990s. In 2018 it was found to be lacking in some
critical areas (encryption types used and other basic mechanism would no
longer be available for post Red Hat 6 systems.)
1-to-1 replacement areas:
Running Batch Jobs:
Our local solution to batch jobs (LSF): The need for TRS was already resolved
with the movement to a new mechanism used for re-authorizing in IBM's LSF
Our remote solution for batch (like) jobs: OSGrid and CVMFS services have no requirement for a TRS type solution. In the area of using remote (full or partial-stack) computing resources from the industry titans, (e.g. Azure, AWS and Google), SLAC-OCIO does not actively use those resources as of March 2019.
Users that run TRScron jobs: a distributed cron service which leverages
the token renewal service, the need remained.
What adaptations should be pondered in the face of future computing workloads?
How does a new vision of TRS compare to past and present mechanisms used to
provide renewable secure access to a distributed service. What are we missing? Comments, questions, and concerns?