Update SessionUser for users who get tokens for multiple customers + roles

[donaldgray]

There might not necessarily be specific work for this but we need to validate that a user can login as multiple different customers, and/or multiple different roles for the same customer (e.g. clickthrough + roleprovider)

Edit - the current iiif-auth-v2 implementation assumes a single session per customer. This has been done as an MVP with clickthrough the only provider. The login logic will need extended to check for the existence of session/cookie and update that as required.

[donaldgray]

May be fixed when we implement dlcs/protagonist#236

[tomcrane]

Do they get multiple maintained sessions (maybe multiple cookies) or does a single session know about multiple logins.

Even for the same customer, a user might acquire a session in different ways - clickthrough first then add Staff would actually be pretty common.

[donaldgray]

Do they get multiple maintained sessions (maybe multiple cookies) or does a single session know about multiple logins.

Discussed internally on Slack, decision was to maintain a single cookie/session per customer which has access to multiple roles.

[donaldgray]

As /logout is per access-service when implementing this we will need to maintain a list of roles assigned per access service. This will require something like the following new fields:

public class RoleProvisionToken
{
  public string AccessService { get; set; }
}

public class SessionUser
{
  public Dictionary<string, List<string>> AccessServiceRoles { get; set; }
}

The former will be used to populate the latter if a significant gesture is required. The latter will track which AccessServiceName:Roles. In the event of a logout operation the roles provided by {AccessServiceName} will be removed from overall Roles list.

The same Role could be acquired in multiple ways so we may need to think about whether a logout operation removes all roles for that service, or only those that haven't also been granted by an alternative access-service.

The alternative approach is to have /logout at a customer level, rather t

Example

If a user accepts a clickthrough agreement they would be granted "dlcs.io/1/clickthrough" and their session would be:

{
    "roles": [
        "dlcs.io/1/clickthrough"
    ],
    "accessServiceRoles": {
        "clickthrough": [
            "dlcs.io/1/clickthrough"
        ]
    }
}

If they then login via OIDC provider they may be granted "dlcs.io/1/clickthrough", "dlcs.io/1/staff", "dlcs.io/1/secret" and their session would be:

{
    "roles": [
        "dlcs.io/1/clickthrough",
        "dlcs.io/1/staff",
        "dlcs.io/1/secret"
    ],
    "accessServiceRoles": {
        "clickthrough": [
            "dlcs.io/1/clickthrough"
        ],
        "oidc": [
            "dlcs.io/1/clickthrough",
            "dlcs.io/1/staff",
            "dlcs.io/1/secret"
        ]
    }
}

What would happen in the following scenarios:

• /access/1/clickthrough/logout - should they lose "dlcs.io/1/clickthrough"? That would make sense but it's also been granted by other means?
• /access/1/oidc/logout - should they lose all 3 roles, or only /staff and /secret ?
• alternatively is the logout at the customer level, rather than access-service? (ie we expire the whole session?)