API: Unauthorized access

[cryp]

Hi.

I'm trying to obtain a file download token via the API using the following curl command:

curl -H "Authorization: FortifyToken <fortifyToken>" -u <user> "<ourFortifyUrl>/ssc/api/v1/fileTokens" -d fileTokenType=DOWNLOAD

The response I get is:

{"message":"Access Denied. Unauthorized access","responseCode":401,"errorCode":-10301}

I can download FPR files via the web GUI. Do I need certain permissions to access the API?

SSC version: 19.1.0.3009

Thanks in advance.

[lvonstockhausen]

Hi

Have you checked the swagger API Reference

the CURL I see there for me looks a bit different after authorizing

curl -X POST "https://<server>/ssc/api/v1/fileTokens" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"fileTokenType\": \"DOWNLOAD\"}"

you find the swagger reference here

https://<server>/ssc/html/docs/api-reference/index.jsp

[cryp]

Hi Ivonstockhausen.

Thanks for your reply. I had not discovered the swagger page - now I don't have to figure out the syntax myself!

Getting a fileToken succeeds when I specify a user and type the password.

However when I try to use an API key, it fails. E.g.:

curl -X POST "https://<ourUrl>/ssc/api/v1/fileTokens" -H "accept: application/json" -H "Authorization: <API key token>" -H "Content-Type: application/json" -d "{ \"fileTokenType\": \"DOWNLOAD\"}"

I have tried using the API key of a CIToken, AnalysisDownloadToken, and UnifiedLoginToken. None worked. I generated the tokens from a user with "universal access" (same user where the request succeeded when specifying username and password).

Can you help?

[dgarozzo]

Looks like you found another API call that currently requires more than a token. I recently opened a ticket for calls to ldapObjects which doesn't work unless you pass in the proper user/pass cookies.

In order for your API call to work, you need to actually log in via the API, collect the cookies in the response, and include those in future requests.

The initial response from the ticket I opened was:

"I have review this case with a more experienced Engineer
That may be the normal behavior, the cookies will have the login credentials to SSC, and the authorization token will allow you to make actions on the API. Both are necessary to use the curl command. When the swagger page is in use and logged into the system the cookies won't be necessary, This is the reason why this only works with the token."

To which I responded with:

"This is not an acceptable answer.

The whole point of having the token is to avoid the need for passing around credentials or including them in scripts.

Using the credentials in conjunction with the token works fine.

I can make many other API calls with just a token, just not the ldapObjects one."

Yeah, I'm a bit frustrated.

[cryp]

Hello dgarozzo.

Thanks for the input.

I used "-c" to save the cookie:

curl -X POST "https://<ourUrl>/ssc/api/v1/fileTokens" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"fileTokenType\": \"DOWNLOAD\"}" -c "cookie.txt" -u <username>

And now it works when using "-b" to attach the cookie (no longer needs user/password or any token):

curl -X POST "https://<ourUrl>/ssc/api/v1/fileTokens" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"fileTokenType\": \"DOWNLOAD\"}" -b "cookie.txt"

I agree that it seems like a bug, that it's not working with API keys. Having cookies laying around is not much better than needing to specify username and password.

But for now, we might use this. I just have one more question: For how long will such a cookie be valid before expiring?

[dgarozzo]

Sorry. Don't know the answer to that one. I've been using my creds by hand instead of using automation for the things that don't work with just a token.

[cryp]

I just tried it again, and it failed. So I guess it has the same expiry as the session timeout duration when logging in to the SSC! Which makes it unusable for continuous integration purposes...

I guess the next best option is to create a user which has only the necessary permissions and then specify username and password for the api-calls.

[dgarozzo]

Be careful. If you use credentials in your automation services, make sure you don't keep creating new tokens. Otherwise, you will create a ton of tokens and blow out the counts of allowed tokens per user.

[ebell]

@cryp 

Here is the command Swagger gives you:

curl -X POST "http://fortify-ssc/ssc/api/v1/fileTokens" -H "accept: application/json" -H "Authorization: ZWE5OGFiNDMtODYwNi00MmY2LWJiOGUtOWJhMTI4MGFiNDIz" -H "Content-Type: application/json" -d "{ \"fileTokenType\": \"DOWNLOAD\"}"

Again, this works in 19.2.0 without issue:

And here it is in PostMan:

The best way to work with/learn the API syntax is to use the Try It Out feature in the Swagger UI - http://{{ssc.url}}/ssc/html/docs/api-reference/index.jsp#/file-token-controller/createFileToken. The first step would be to click the Authorize button at the top of the page. You can use either Basic Authorization or a token (UnifiedLoginToken).

[ebell]

@dgarozzo 

What version of SSC are you running? I am unable to duplicate this issue running SSC 19.2.0. Here is my curl command from SSC Swagger:

curl -X GET "http://fortify-ssc/ssc/api/v1/ldapObjects?start=0&limit=200" -H "accept: application/json" -H "Authorization: ZWE5OGFiNDMtODYwNi00MmY2LWJiOGUtOWJhMTI4MGFiNDIz"

As you can see from the screenshot below, I  get a 200 with data:

cURL from Postman:

curl --location --request GET 'http://fortify-ssc/ssc/api/v1/ldapObjects' \
--header 'Authorization: FortifyToken ZWE5OGFiNDMtODYwNi00MmY2LWJiOGUtOWJhMTI4MGFiNDIz'

or translated into PowerShell:

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Authorization", "FortifyToken ZWE5OGFiNDMtODYwNi00MmY2LWJiOGUtOWJhMTI4MGFiNDIz")

$response = Invoke-RestMethod 'http://fortify-ssc/ssc/api/v1/ldapObjects' -Method 'GET' -Headers $headers -Body $body
$response | ConvertTo-Json

 

[dgarozzo]

@ebell Looks like they fixed the problem in 19.2 then. I'm still on 19.1. Thanks for the info!

Sad that I didn't get that response in the ticket that I opened (and is still open).

[ebell]

@dgarozzo 

Understood.

I put an "internal" update in the ticket the same time I posted the information here in the forum. The only difference being the update in the ticket was EOB and sent back to the tech assigned for follow-up with you. You should be receiving that information today.