...
- we have a pool of EC2 hosts running RStudio server behind a load balancer with CNAME rstudio.sagebase.org
- use the sticky load balancing feature http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
- our services and the custom RStudio auth plugin share a secret key for use in HMAC-SHA1 computation
- if someone on Synapse wants to use RStudio, we redirect them to https://rstudio.sagebase.org:8787/auth-sign-in?expires=1317916890&signature=rucSbH0yNEcP9oM2XNlouVI3BH4%3D with HTTP header sessionToken:XXXXXXXX
- stickiness is on the sessionToken header, it is also used to log the user into Synapse
- this url must be used within 5 minutes to start an RStudio session
- the RStudio auth plugin re-computes the signature on expires=1317916890&sessionToken:XXXXXXXX
- if it doesn’t match, the user gets a helpful error message
- if it does match, but the url has expired, the user gets a helpful error message
- if it does match and the url is not expired
- we use a stable method to compute a unix username from the Synapse securityToken, this username should be no longer than 32 characters
- perform useradd and make the home directory
- Needs more thought: RStudio Server doesn't run as root so it may contact some daemon running on the box to do the things requiring root privilege, think about what the API between RStudio and the daemon should be
- use a template .RProfile to install a .Rprofile in the new home directory to
- load and log them into the R Synapse client
library(synapseClient); sessionToken(securityToken) - add a package installation directory under the user's home dir if they want to install their own R packages
- perhaps configure utilization the shared cache of Synapse data (if we can sort out the data security issues)
- load and log them into the R Synapse client
- When the users logs out, nuke that unix account and the home directory
...