Need for token as session id?

[Marc Boorshtein]

I'm working on https://github.com/kiali/kiali/issues/3207 and want to know if there's any reason, beyond needing to be unique, that the sessionid returned to the ui is the original token?  For impersonation, the token is usually a service account that the user should never be shared with the user.  Is there a reason I couldn't just use a type iv uuid?

Thanks

Marc

[Edgar Hernández]

Hi Marc,

The only reason is because Kiali is stateless and there is no back-end storage.
The UI does nothing with it. The UI even can't read the token because it's stored in an HTTP-Only cookie. It's there only for the back-end to read it on subsequent requests.

My understanding is that using UUIDs, or any other kind of ID will require back-end storage to save the mapping of UUID-to-tokens.
Memory is the only storage we have available. In a non-kubernetes environment, using memory as storage is OK. However, in Kubernetes workloads are ephemeral which means that memory storage is unreliable.

That said, if you have a fully state-less way of using UUIDs and still have a way to retrieve the associated serviceaccount token for subsequent requests, you are free to use UUIDs as sessionId.

--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/fdec5f0f-8cc4-4f4a-ad6a-c586bfd2b91cn%40googlegroups.com.

[Marc Boorshtein]

The only reason is because Kiali is stateless and there is no back-end storage.
The UI does nothing with it. The UI even can't read the token because it's stored in an HTTP-Only cookie. It's there only for the back-end to read it on subsequent requests.

Got it, so the UI doesn't care about the information, only the backend?

 

My understanding is that using UUIDs, or any other kind of ID will require back-end storage to save the mapping of UUID-to-tokens.
Memory is the only storage we have available. In a non-kubernetes environment, using memory as storage is OK. However, in Kubernetes workloads are ephemeral which means that memory storage is unreliable. 

That said, if you have a fully state-less way of using UUIDs and still have a way to retrieve the associated serviceaccount token for subsequent requests, you are free to use UUIDs as sessionId.

I see.  In this case the only token used is the one coming in from the request on each each request.  My plan is to update business.Get(token) --> business.Get(api.AuthInfo) to give each request the ability to set a token and impersonation headers from the reverse proxy.  So if we're setting the auth info on each request, there's no need for any kind of session info, right?

 

Thanks

Marc

[Edgar Hernández]

On 1/4/21 9:53 AM, 'Marc Boorshtein' via kiali-dev wrote:

The only reason is because Kiali is stateless and there is no back-end storage.
The UI does nothing with it. The UI even can't read the token because it's stored in an HTTP-Only cookie. It's there only for the back-end to read it on subsequent requests.

Got it, so the UI doesn't care about the information, only the backend?

 

Yes, the UI doesn't care.
However, there is an endpoint (/api/auth/info) that the UI calls to get the username. The back-end tries to extract the username from the token.
Strictly speaking, the UI doesn't care where the username came from. Yet, that info is related to the token. It's something to keep in mind when changing the auth methods.

My understanding is that using UUIDs, or any other kind of ID will require back-end storage to save the mapping of UUID-to-tokens.
Memory is the only storage we have available. In a non-kubernetes environment, using memory as storage is OK. However, in Kubernetes workloads are ephemeral which means that memory storage is unreliable. 

That said, if you have a fully state-less way of using UUIDs and still have a way to retrieve the associated serviceaccount token for subsequent requests, you are free to use UUIDs as sessionId.

I see.  In this case the only token used is the one coming in from the request on each each request.  My plan is to update business.Get(token) --> business.Get(api.AuthInfo) to give each request the ability to set a token and impersonation headers from the reverse proxy.  So if we're setting the auth info on each request, there's no need for any kind of session info, right?

 

Right! If the reverse proxy is providing the needed data, no need for session info. Just use the data in the headers.

Thanks

Marc

--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/b3e7b133-c7c7-4105-84b6-217f792e69c2n%40googlegroups.com.

[Marc Boorshtein]

Yes, the UI doesn't care.
However, there is an endpoint (/api/auth/info) that the UI calls to get the username. The back-end tries to extract the username from the token.
Strictly speaking, the UI doesn't care where the username came from. Yet, that info is related to the token. It's something to keep in mind when changing the auth methods.

Right, got that part covered

  

Right! If the reverse proxy is providing the needed data, no need for session info. Just use the data in the headers.

Awesome!  Going through the code it looks like the k8s client is cached based on the token.  since the token is no longer unique per user i'll need to create a hash of the token and impersonation data if it's there.

Thanks