Why do I get redirected to the login screen when starting a workspace or job?

There are two mechanisms in Domino related to credential propagation that can cause this behavior.  These are token propagation features and are intended to allow access to secure resources while in Domino jobs and workspaces.  

There is an implicit security concern underlying the question of being redirected back to login after being in the UI for some time, but any time a user is in the Domino UI they have an authenticated Domino login.  So why do you sometimes get directed back to login when starting a workload?

The two mechanisms involved are AWS Credential Propagation and JWT Credentials Propagation.  If this already sounds like more than you may want to know, rest assured that if a user is in the Domino UI, they have an authenticated session.  And sometimes being redirected to login when starting a workload is expected behavior in order to ensure that all credential tokens are valid.  

We understand this behaviour can be somewhat confusing and a little annoying at times, we are working to improve the user experience with these credentials features.  Keep reading if you would like the gory details.

AWS Credential Propagation

AWS credential propagation is not enabled by default but can be enabled by your system administrator.  Occasionally being redirected to the login screen is currently a side effect of this feature.

This feature allows users to access secure AWS resources, such as S3 buckets, seamlessly in workspaces and jobs.  So as a user, if you are uncertain whether this is in use, reach out to your local Domino admin to see if this is enabled. If your admin is unsure they can verify by looking in the Central Configuration settings under admin>>advanced>>Central Configuration in the Domino UI to see if the following is set to 'true'

com.cerebro.domino.auth.aws.sts.enabled

If not present in Central Config the value is the default value of 'false'.  If true, the feature is enabled in your Domino deployment for all users.  This can create a situation that forces a user to the login screen to refresh their AWS token.

Why does this happen?

So why does starting a workload force a login?  

The following sequence of events is why this happens...

1) A user enters the Domino UI, they either have a pre-existing session that was previously validated via whatever authentication method is in use on the deployment, SSO, for example or they came in via the login page and logged in to create a new session.  So all users in the Domino UI are always authenticated. 

2) Upon login to the UI, Domino reaches out to AWS and establishes an AWS session token based on predefined SAML information.  This AWS session token has an expiry defined by your admin, but has a maximum of 12 hours. 

3) The user then enters the Domino UI again some time later and their Domino login session is still valid.  In the meantime, however, their AWS token may have expired.  When you try to start a workload, we check that the AWS token is still valid.  If it has expired we send the user back to the Domino login to force them through the login again to re-establish the AWS token.  Although Domino authentication is also re-established by this process, it is fundamentally not the purpose as the Domino login is still valid or the user could not be in the UI.  

JWT Credential Propagation

JWT Credential Propagation is similar to AWS credential propagation, but it gives users access to secure objects from Domino itself.   Unfortunately being redirected to a login prompt is similarly a side effect of this mechanism as well.

This is typically enabled by default, but can be verified in the same central config location by checking if the following setting is 'true'.  If the key value is not present then it is at the default setting of 'true'.

com.cerebro.domino.auth.refreshTokenInRun.enabled

As noted, the JWT token gives access to secure elements in the Domino UI such as API requests.  Much like the AWS session token, it is populated in to the running workloads on startup and so must be valid.  This means we verify that it has not expired on startup of a workload. If expired we again redirect the user to the login screen to get a fresh session token.

This can definitely be confusing and concerning behavior so look for this to be more seamless in an upcoming version.