Work around eduTEAMS delay for newly provisioned users and free-ride services

[baszoetekouw]

EduTEAMS has a bug which causes a delay for newly provisioned users to become known to the proxy. In practice this is not a problem, except in the case that a previously unknown user directly accesses a free-ride service.

In that case, they log in at the service, are provisioned in eduTEAMS, get redirected to SBS (for AUP, MFA etc), and SBS requires a secondary AuthN. This authentication then fails at eduTEAMS because the user is only partially known.

As a workaround for this problem, we need to introduce a fixed 20-second delay for these types of users. These users and up in SBS in the AUP page {base_url}/service-aup end can be recognized by the status NEW_FREE_RIDE_USER = 97 in the parameters . See

• 1462

for the implementation on the service side.

So on the service-aup page, we need to have a 20-second countdown before the user can continue. Let put a text there explaining what is happening:

Please stand by while we create your account. Excuse us for this one-time delay.

Even geduld alstublieft terwijl we uw account gereed maken. Onze excuses voor deze eenmalige vertraging.

with some nice animated clock/timer/bar that shows that something is actually happening.

[baszoetekouw]

BTW, a very basic number countdown would also be fine; this won't be seen by may users anyway, and we can always make it fancier later on.

[oharsta]

Can be tested on the test environment by visiting: https://sbs.test.sram.surf.nl/service-aup?service_id=0865b0c6-613e-4879-a6ca-9f5b99d67f46&service_name=Storage&status=97&continue_url=https%3A%2F%2Fproxy.acc.sram.eduteams.org%2Fcontinue

[baszoetekouw]

Hmm, again our overly complex authn flow is in the way. It turns out that the /service_aup page asks the user to login before showing the delay. That login then end on a dead end at EduTEAMS, because we need the delay exactly to work around that problem.

So what is the best solution here? Can we add the delay before requiring the login on /service_aup? Of would it be easier to add a new "delay" page that only handles the delay and then forwards to user to whatever page they were going to?

So something like:

• proxy_authz returns redirect_url=https://sram/delay?nextpage=service-aup&service_id=<uuid>&service_name=Wrong%20Trousers
• eduTEAMS redirects to https://sram/delay?nextpage=service-aup&service_id=<uuid>&service_name=Wrong%20Trousers&continue_url=https://proxy/continue/1234
• delay page waits 20 seconds
• forwards user to https://sram/service-aup?service_id=&service_name=Wrong%20Trousers&continue_url=https://proxy/continue/1234`
• lets user login again (should work after the delay)
• handle AUP
• redirect to https://proxy/continue/1234
• ...

[oharsta]

Fixed in https://github.com/SURFscz/SBS/commit/a02c05097151035f7b4140279649fa4523b42206

[oharsta]

Can be tested with https://test.sram.surf.nl/delay?service_id=0865b0c6-613e-4879-a6ca-9f5b99d67f46&service_name=Storage&status=97&continue_url=https%3A%2F%2Fproxy.acc.sram.eduteams.org%2Fcontinue

[baszoetekouw]

confirmed