Revisit auth session timeout

[mythi]

Originally reported as item 3 in #162

Session timeout
there seems to be a conflict with how long the attestation results are valid: 1) KBS could set some long session timeout but the AS token can theoretically have much shorter lifetime which is ignored by the resource API (get_attest_claims_from_session()). 2) KBS could set some short session timeout (shorter than the token exp) but CDH can still pull resources longer than that since the token is still valid.

Suggestion: drop the timeout setting and make the session timeout to follow JWT token's exp?

[Xynnn007]

The timeout is the session timeout. It does not directly determine whether the target plugin/resource can be accessed. Thus I am afraid that there is nothing needed to fix.

What the session stores is only the attestation token. If the session is expired, the attestation should be carried along with the requests' HTTP Auth Header, or the access will fail and a new RCAR handshake would be performed by client.

Either the token is expired or the session is expired (without a token along with http request), a new RCAR handshake would be performed by client.

When token is got, its expired time will be checked.

[mythi]

IIRC my original thinking was just that is the user-configurable timeout necessary if we think that AS defines how long the token is valid and how often it's good to do re-attestation. CoCo AS also has a timeout config so perhaps one place is enough?

[Xynnn007]

IIRC my original thinking was just that is the user-configurable timeout necessary if we think that AS defines how long the token is valid and how often it's good to do re-attestation. CoCo AS also has a timeout config so perhaps one place is enough?

They are different things. One is the expired time of attestation token, and the other is the maximum time to keep the session. The coincidence is that they both are named timeout.

If we abondon the session mechanism, this means every secret access request should carry the token inside the http header w/o cookie, we do not need timeout for kbs.

[fitzthum]

Yeah note that since the last refactor we use this code to get the claims from the session by verifying the token. I think this is slightly different from the old approach where we could get the claims from the session itself and not re-verify the token. Now we can check that the token is valid when we verify it. Note that the JWK token verifier doesn't currently seem to do this.

As for whether the session timeout should match the token expiration, I don't think it really matters.

I do have one remaining question about the session. When people don't use HTTPS the session data isn't protected. This isn't an issue for the token because it is signed, but what about during the RCAR handshake?

[Xynnn007]

This isn't an issue for the token because it is signed, but what about during the RCAR handshake?

What do you mean by things during RCAR handshake?

[mythi]

Looks like the client code has some token expiration check logic too..