rsenden
commented
1 year ago Hi, what makes you think that you can use an encrypted token on the login command? The help output for the crypto commands only mention some specific fcli commands where encryption would be useful, and the login commands are not mentioned.
Maybe the confusion comes from the help output for the fcli ssc session login command, which states hat either an encoded or decoded token can be provided? This corresponds to the terminology used in the SSC web UI, and 'encoded' is not the same as 'encrypted'. The fcli ssc token create command names this as Rest token and Application token; fcli accepts either one of these to be passed to the login command. Maybe we should make more clear that 'encoded' and 'decoded' correspond to 'Rest token' and 'Application token'?
The SSC session login command indeed doesn't currently validate the token as there is no SSC API endpoint for token validation, although we do plan on at least checking that the token is in a valid format (see #168 , #197 and #295). After resolving #295, you would receive an error message stating that the token is not in a valid format if you attempt using an encrypted token.
As for the concern about sniffing the traffic, that's why SSC should only be accessible over HTTPS. SSC doesn't support encrypted tokens, so fcli can't send any encrypted tokens.
xakrurychle
I just want to confirm whether my flow with using encryption is correct or not.
1) Basic token creation
fcli ssc token create AutomationToken --user <user> --password <pass>2) Encrypting the token obtained with command in step 1
fcli util crypto encryptValue to encrypt: YTFkN2Q5ZWItZmYyZS00NmJiLTkyZjMtYWYyZWY0MDMwMmExResult Wn9UziTkm5g4T8qCBbJ+AvMvIbauWKE43woRvB5lzG+QkdgqA5Cw2N4oqVw+GUHSqBknJ4oZGpDekmH9LU6nidf9JrAI6+9Wa2SJW2XwuiMmB20qcmZVl838IJibaX33
3) Using encrypted token from step 2 to create encrypted session
4) Listing sessions
fcli ssc session ls5) Using default session
fcli ssc app ls6) Using session created by encrypted key
fcli ssc app ls --session encryptedSession7) Creating named and not encrypted session to double check --session flag itself is working
fcli ssc session login notDefault --url $url --user <user> --password <password>[qaprague@qa-st-c7-kho01 fcli_v3]$
fcli ssc app ls --session notDefaultHere I know for sure that --session works if not using encrypted session. The question is if there is something wrong with my flow and how I created the session using the ecrypted token?
fcli ssc token create AutomationToken --user krystof --password admin> notCryptedSession.key [qaprague@qa-st-c7-kho01 fcli_v3]$cat notCryptedSession.keyId Username Type Rest token Application token Terminal date Time remaining Description 345 krystof AutomationToken MDk4MTUxM2YtNDI3OC00ZThkLTljNmEtYmM0ZWEyNGZiYWQw 0981513f-4278-4e8d-9c6a-bc4ea24fbad0 2024-06-28T13:16:25.290+00:00 365 days Generated by 'fcli ssc token create' command[qaprague@qa-st-c7-kho01 fcli_v3]$
[qaprague@qa-st-c7-kho01 fcli_v3]$
fcli ssc app ls --session notEncryptedSessionAt this step I know that using NOT crypted token the flow works too… What else would I be using encrypted key for? My assumption is that the key from
-toption is part of GET/POST/UPDATE requests and if someone can sniff the traffic, they would see the plain value, therefore the reason for using-t <encrypted>, but using the encrypted session fails, although it was allowed to be created in the first place.Maybe my flow is wrong since step 3, in that case is there no check that user is using proper key format/lenght etc to disqualify creation of the session in the first place?