Auto-generate booking-duration tokens for services such as logging, report video, enthalpy, chat.

[timdrysdale]

We now need the capability to auto-generate tokens for services other than relay. Examples include logging service, task compare, video quality report button, enthalpy calculation, chat API - these services might vary in future in such a way that we should be able to specify them in manifest, rather than hard code them in as we do for relay (which is a core service). In this way, we don't have to update the relay code base.

Tokens for relay streams are generated here, for reference:

book/internal/serve/usershandlers.go

Line 807 in 306d218

for k, v := range a.Streams {

There are different items put in the token than in the info about the token, including some non-standard fields. We ought to suport non-standard fields, but there may be some limitation on how deeply we can nest them.

token

			permission := Permission{
				BookingID: b.Name,
				Topic:     st.Topic,
				Prefix:    st.ConnectionType,
				Scopes:    st.Scopes,
				RegisteredClaims: jwt.RegisteredClaims{
					IssuedAt:  now,
					NotBefore: now,
					ExpiresAt: later,
					Subject:   params.UserName, //adding for future usage
					Audience:  jwt.ClaimStrings{st.URL},
				},
			}

streams object

			stm := gog.Ptr(models.ActivityStream{
				Audience:       gog.Ptr(st.URL),
				ConnectionType: gog.Ptr(st.ConnectionType),
				For:            gog.Ptr(st.For),
				Scopes:         v.Scopes,
				Topic:          gog.Ptr(st.Topic),
				URL:            gog.Ptr(st.URL + "/" + st.ConnectionType + "/" + st.Topic), //this is the URL the UI attempts to connect to, so must be complete
				Token:          stoken,
			})

For autogeneration, we can cover start time and end time automatically. We can also add the uuid to the token, because that is known from the booking. Where it gets trickier is if the path needs to include the user, but presumably we can rely on the service provider to know how their routings are structured and check that the user in the token matches the user routing in the path.

It may be that we need templating to allow substitution of the experiment name in information given

The current manifest format is as follows:

stream protypes (examples)

  st-data:
    url: https://app.practable.io/ed0/access
    connection_type: session
    for: data
    scopes:
      - read
      - write
    topic: auto
  st-video:
    url: https://app.practable.io/ed0/access
    connection_type: session
    for: video
    scopes:
      - read
    topic: auto

experiment entry

resources:
  r-frig00:
    description: d-r-fridge-gunt
    streams:
      - st-data
      - st-video
      - st-video-b
      - st-video-c
    topic_stub: frig00

The auto keyword does nothing - the topic is generated from the getActivity function

book/internal/serve/usershandlers.go

Line 781 in 306d218

a, err := config.Store.GetActivity(b)

This suggests that the knowledge required by book is quite tightly coupled to the services, if book is to autogenerate tokens. It may be better to devolve the responsibility for autogenerating tokens to the new services themselves (or their representatives, as the services may be developed by students and not have the capacity to serve tokens as well). The devolved approach adds lots of overhead in the simplest case, though.

In the simplest case, a generic approach of including the experiment, group, and user name, for a defined host, would offer only a basic level of access control e.g. over read/write, admin/user status etc. Unless a generic parameters object, that is fixed by writing it in manigest is used - which probably gets us a fairly long way along the line. Moving to full zanzibar approach here would have benefits but also significant overhead in terms of account set up (At this time, not yet implemented).

Nested claims in jwt are not forbidden, nor are they necessarily ideal. One possibility is to allow a claims array in manifest that gets flattened into separate claims.

Similarly, an info section for the user interface could be an array object in the manifest that is flattened into separate keys in the UI info