Creating JWS session tables

So client authenticates, token generated by server would be stored on BIG-IP, and a new one generated by BIG-IP and sent to client, with a mapping of clientside/servside tokens managed on BIG-IP?

Does the client need to do anything with this token other than use it for further inbound communications? Are all those communications coming back to same BIG-IP? Does this data need to persist a failover? A reboot?

The token will only be used for further inbound comms as you mentioned.

All flows are passing the same BIG-IP.

Sorry, I forgot to answer the last question. It's not essential to do any connection mirroring. The worse case is the client connects without an external session token and the F5 just proxies the flow as if it was a token-less flow.

The workflow for a new connection should be as follows:- -1: Client connects without external session token --> F5 --> proxies connection to API server -2: API server responds with JWS token --> F5 populates table with JWS and generates an external session token. This is mapped against the original JWS in a reference table --> JWS is replaced by external session token in response to client (Client side connections should not contain JWS)

The workflow for a existing connections should be as follows:- -1: Client connects with external token --> F5 checks if the external token still exists in the reference table (depending on token validity). If the token exists then it should be mapped to an internal JWS token which is rewritten in the header of the server side flow --> proxies connection to API server

If the above flow contains an external token which has expired then it should have been removed from the reference table, thereby the F5 will proxy the flow to the API server without a JWS. The API server will redirect the client to restart the authentication chain.

I hope this clarifies the requirement. Many thanks in advance for your support.

Yep, that's clear. Totally doable with an iRule, and you can store the data in the session table via the table command with the external token being the key and the internal token being the value. Pseudo code would be something like:

when HTTP_RESPONSE {
  set key 
  table set $key $internal_token $expiration_in_seconds
}
when HTTP_REQUEST {
  set int_key [table lookup $ext_key]
  if { $int_key ne "" } {
    HTTP::header replace header int_key
  }
  else { HTTP::header remove header }
}

Hi Jason,

Thanks for the info. I'm not an advanced iRules user. Maybe I'm wrong, but I'm missing the following:-

• What value is taken for the $internal_key variable? In the case of our implementation, it will be the payload portion of a JWT

   

• How will the &ext_key variable be derived?

   

• In HTTP_REQUEST, there is a table lookup, but how is the match done against the value of the external key in the header itself?

   

Thanks

What value is taken for the $internal_key variable?

 

 

In both cases, you'll likely need to use the HTTP::header command, to extract the JWT token from the serverside-flow and to provide the F5 supplied cookie on the first connection, and to read the f5 supplied cookie and map that to the internal JWT.

 

Hi Khalid, I gave you a construct for your code, not the code itself. As Rob indicated, you'll need to fill in the gaps there because we don't know the headers or payload you are using. You also need to decide how to generate an external token for your internal one. You can make it random and just map it, but you would be more susceptible to collisions that way than just creating a hash of the internal token and using that.

OK. That's clear. As soon as I get a pcap of the flow I can start building the iRule. If the Hash is considered secure then using the original token is a great idea.

What about performance impact? How far can this scale on a BIG-IP 2000 platform if I will store the entire JWT (internal) and it's hash (external) in the table?

you'll need to test in small scale and extrapolate. the session table is memory, so you'll need to do the math on your token size, the hash of that token, and then the number of active tokens you'd expect to be in the system at any given time.

I'm putting together the iRule but having issues understanding how to search an entry in a table.

Using Jason's pseudo code posted previously, is it safe to assume that the variables $key and $internal_token set in the HTTP_RESPONSE section will still be valid as variables for the table Keys and Values in the HTTP_REQUEST section? If that is the case then I can work with that.

If not, then how do I refer to table Key and Value strings? I need to search for a Key in a table and get it's corresponding Value. I won't be searching for a specific string, rather searching if the header contains a Key or Value string which exists in the table then call it's corresponding Key or Value (and vice-versa.

I hope my explanation was clear.

Thanks