Forum Discussion

Jeff_Green_4244's avatar
Jeff_Green_4244
Icon for Nimbostratus rankNimbostratus
Nov 07, 2011

Create Domino LTPA token on F5 problem

Hi,

 

 

I'm trying to use the code at

 

 

http://per.lausten.dk/blog/2009/06/how-to-create-a-ltpa-session-cookie-for-lotus-domino-using-f5.html

 

 

to create a Domino LTPA token but I am getting the following error showing on the Domino server:

 

Token does not lead with 0 [Single Sign-On token is invalid].

 

 

The token should begin with the version number 0123 e.g. from the code

 

set ltpa_version "\x00\x01\x02\x03"

 

 

However, after decoding the token and then looking at it in a hex editor the version number shows as:

 

 

C0 80 01 02 03 .......

 

 

Can somebody explain to me why the \x00 is being changed to C0 80 please?

 

 

I've experimented putting other numbers in thefirst position to see what happens e.g. \x01\x01\x02\x03 and the hex readout looks correct i.e. 01 01 02 03. It only fails when I use a \x00 in the first position.

 

 

Thanks for any suggestions.

 

Jeff

 

16 Replies

  • Hi everyone,

     

     

    Thanks for the input. I have opened a support case and will report back once they figure it out.

     

     

    regards,

     

    Jeff
  • F5 have asupplied a workaround that seems to be doing everything correctly. We're going to test more thoroughly before declaring victory. The relevant line in the code is:

     

     

    
      Create binary formatted token.
     set ltpa_token_raw_bin [binary a* $ltpa_token_raw]
    

     

     

    Here's the entire code that seems to be working:

     

     

    
    when RULE_INIT {
     set ::DEBUG 0
     set cookie_name "LtpaToken"
     set ltpa_version "\x00\x01\x02\x03"
     set ltpa_secret "b64encodedsecretkey"
     set ltpa_timeout "1800"
    }
    
    when HTTP_REQUEST {
     
      Do your usual F5 HTTP authentication here
     
    
      Initial values
     set now [clock seconds]
     set creation_time_temp [expr { $now }]
     set creation_time [format %X $creation_time_temp]
     set expr_time_temp [expr { $creation_time_temp + $::ltpa_timeout}]
     set expr_time [format %X $expr_time_temp]
     set username [HTTP::header "username"]
     set ltpa_secret_decode [b64decode $::ltpa_secret]
    
      First part of token
     set cookie_data_raw {}
     append cookie_data_raw $::ltpa_version
     append cookie_data_raw $creation_time
     append cookie_data_raw $expr_time
     append cookie_data_raw $username
     append cookie_data_raw $ltpa_secret_decode
    
      SHA1 of first part of token
     set sha_cookie_raw [sha1 $cookie_data_raw]
    
      Final not yet encoded token
     set ltpa_token_raw {}
     append ltpa_token_raw $::ltpa_version
     append ltpa_token_raw $creation_time
     append ltpa_token_raw $expr_time
     append ltpa_token_raw $username
     append ltpa_token_raw $sha_cookie_raw
    
      Create binary formatted token.
     set ltpa_token_raw_bin [binary a* $ltpa_token_raw]
    
      Final Base64 encoded token
     set ltpa_token_final [b64encode $ltpa_token_raw_bin]
    
      Insert the cookie
     HTTP::cookie insert name $::cookie_name value $ltpa_token_final
    
    
      Loop through the list of Cookie headers to remove
      superfluous trailing semi-colons (known F5 issue)
      if they exist.
      
      Save the Cookie headers to a TCL list
     set cookie_headers [HTTP::header values "Cookie"]
    
     foreach cookie_header $cookie_headers {
        Check if the last character is a semi-colon
       if {[string range $cookie_header end end] eq ";"}{
         HTTP::cookie remove LtpaToken
          Insert the header without the semi-colon
         HTTP::header insert Cookie [string range $cookie_header 0 end-1]
         } else {
          Insert the original header
         HTTP::header insert Cookie $cookie_header
         }
       }
       
      Remove Authorization HTTP header to avoid using basic authentication
     if { [HTTP::header exists "Authorization"] } {
     HTTP::header remove "Authorization"
     }
    
     if {$::DEBUG} {
       binary scan $ltpa_token_raw H* ltpa_token_raw_hex
       log local0.debug "LTP_TOKEN raw Hex: $ltpa_token_raw_hex"
       binary scan $ltpa_token_raw H* ltpa_token_raw_hex_bin
       log local0.debug "LTP_TOKEN raw_bin Hex: $ltpa_token_raw_hex_bin"   
       set ltpa_final_decoded [b64decode $ltpa_token_final]
       binary scan $ltpa_final_decoded H* ltpa_final_decoded_hex
       log local0.debug "LTP_TOKEN decoded Hex: $ltpa_final_decoded_hex"
     }
    }
    
  • That alomst came out correct. The relevant line was:

     

     

    Final Base64 encoded token

     

    set ltpa_token_final [b64encode $ltpa_token_raw_bin]
  • Hi Jeff,

     

     

    Thanks for posting the solution.

     

     

    If you're on 10+ you can replace the global variables in RULE_INIT with static variables. This will function the same, but be CMP compatible. Using the global variables will prevent the iRule (and VS) from being processed on more than one TMM:

     

     

    http://devcentral.f5.com/wiki/iRules.CMPCompatibility.ashx

     

     

    There's a bug with the DC forums code when you use more than one code block in the quick reply box. You can click Edit on your corrupted post and then submit it as is to have it rendered correctly. Or you can click the reply button instead and use the full reply function instead of the quick reply option.

     

     

    Aaron
  • Hi,

     

     

     

    i stay in front of the same challenge like jeff and try to implement LTPA token creation incl. Reverse Proxy with SSO. This is all new for me. We use 10.2.2 @ LTM incl. ASM.

     

     

     

    So, if i try to create an irule with Jeff's code from above i get an syntax validation error in Irule editor:

     

    Create binary formatted token.

     

    set ltpa_token_raw_bin [binary a* $ltpa_token_raw]

     

    --> [invalid option "a*" must be: format scan] [a*]

     

     

     

    so for me, it looks like the line should be replaced by this:

     

    set ltpa_token_raw_bin [binary fromat a* $ltpa_token_raw]

     

     

     

    can someone confirm that behaviour?

     

    Thx

     

  • Hi Team. Anyone have this working still? We are running BIG-IP 11.3.0, Domino 8.5.2, and I am struggling to get the code to produce a valid encoded token. Can anyone share an example of the set ltpa_secret "b64encodedsecretkey" field, to give me a clue to what this should look like? Is this a direct copy out of the LTPA document in Domino LTPA_DominoSecret field, or do I need to change that value prior to insert into the iRule? Thanks in advance!