CF-Access-Client-Id not even recognized

Zero Trust Access
1

Hi,

I am currently trying to implement Cloudflare’s Zero Trust network, yet I am hitting a roadblock, so I hope that someone here can help me.

I have configured everything, setuped a tunnel, SAML with Azure and Google for authentication and everything works beautifully. Yet now I need to allowlist a service to access / bypass CF Auth. So I configured under “Service Auth” a “Service Token” and allowlisted it in the Application

image
image1306×1195 48.4 KB

But when I modify my API call and send the appropriate headers, I am always seeing a 302 redirect to https://dummy.cloudflareaccess.com/cdn-cgi/access/login/test.corp.com?kid=...

The request details:

POST /xmlrpc/2/common HTTP/1.1
Host: test.example.com
CF-Access-Client-Id: abcdefghi...access
CF-Access-Client-Secret: c12345.......c
Accept-Encoding: gzip
Content-Type: text/xml
User-Agent: Python-xmlrpc/3.10
Content-Length: 368

And the response:

reply: 'HTTP/1.1 302 Moved Temporarily\r\n'
header: Date: Fri, 14 Apr 2023 20:07:02 GMT
header: Transfer-Encoding: chunked
header: Connection: keep-alive
header: Set-Cookie: CF_AppSession=n47112f964efad79c; Expires=Sat, 15 Apr 2023 20:07:02 GMT; Path=/; Secure; HttpOnly
header: Access-Control-Allow-Credentials: true
header: Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
header: Expires: Thu, 01 Jan 1970 00:00:01 GMT
header: Location: https://hidden.cloudflareaccess.com/cdn-cgi/access/login/test.example.com?kid=b131ac7d5b196835fe187d809df98c7ee2f37f2704d33375c2c4ba9918f72d7a&redirect_url=%2Fxmlrpc%2F2%2Fcommon&meta=eyJraWQiOiI5NTI1MjBmMDE2MWRhNDU5YzMzNmUzN2QzOGE2Y2EwNjEzYjViY2UyMGI2OWEyNWIwMGM1NTM4NmU1NTEyODA0IiwiYWxnIjoiUlMyNTYiLCJ0eXAiOiJKV1QifQ.eyJzZXJ2aWNlX3Rva2VuX3N0YXR1cyI6dHJ1ZSwiaWF0IjoxNjgxNTAyODIyLCJzZXJ2aWNlX3Rva2VuX2lkIjoiNzM0OTVmNTQtZjY3MS00YjY1LWFlYzQtNmYyNTVhY2Q3OGI2IiwiYXVkIjoiYjEzMWFjN2Q1YjE5NjgzNWZlMTg3ZDgwOWRmOThjN2VlMmYzN2YyNzA0ZDMzMzc1YzJjNGJhOTkxOGY3MmQ3YSIsImhvc3RuYW1lIjoib2RvbzIuZXNhcWEuY29tIiwiYXBwX3Nlc3Npb25faGFzaCI6IjMwNjZhODY1ODhlMzE3ZmFlYTAxM2FjMzU2ZmNhNjkzYTcxNTM2ODcwZmJhNmI2NTUyMmVmYmJmYjMxNmM2MGMiLCJuYmYiOjE2ODE1MDI4MjIsImlzX3dhcnAiOmZhbHNlLCJpc19nYXRld2F5IjpmYWxzZSwidHlwZSI6Im1ldGEiLCJyZWRpcmVjdF91cmwiOiJcL3htbHJwY1wvMlwvY29tbW9uIiwibXRsc19hdXRoIjp7ImNlcnRfaXNzdWVyX3NraSI6IiIsImNlcnRfcHJlc2VudGVkIjpmYWxzZSwiY2VydF9zZXJpYWwiOiIiLCJjZXJ0X2lzc3Vlcl9kbiI6IiIsImF1dGhfc3RhdHVzIjoiTk9ORSJ9LCJhdXRoX3N0YXR1cyI6Ik5PTkUifQ.n97u96v8Xn-wXxRzXXaF-MU1Ohen1HMKT1OclTts73KKtyMe_H8IspFhkaAHvjm4ApwV0vFnMTjnK2yKSgxRcDUU5yXsrtgEVSVo4WPSGVHydU2b59WNcumUr9kmWo5yhAa2ibRq0MD-OwmtFy5ZifGTzqx3xyAo01GgxSR32BMcqwJ3JlzvfZYBcNVRa3zB66rr-kzL0OfezE9aImsSSM5oqgNUDTQwl_lmVhKOF9JEsM9fV1E1VUFTKnI3Zi6wbsxdZTBOvrvZmeLQpuJDh0FyHMshlFwD2TL79KIgOxDa6546M4NgHUGZpHzjeUg4NHjE-dA8aAZi9sl5tm96UA
header: Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=nfWbJ9QsUqcs9PNUeCl52jp9ZGM7z%2BducmO%2B1niNJUK6v4CLQ2CzXxHmWpJaUZfce6A1jZ6UwGtTf2IwUusi3ewBQYJaf4l%2B7aShu3M475%2FgJ8K12SruUYL3LhIgqJ2d4Do%3D"}],"group":"cf-nel","max_age":604800}
header: NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
header: Vary: Accept-Encoding

In the portal the Service Token is also shown as “Never Used”.

Thank you very much in advance. Any help is much appreciated!

Best regards
Sascha

4

Found a solution. Previously I had one “Allow” policy, that contained the Azure Group allowlisting and the Service Access Token. It seems that “Allow” together with “Service Access Token” doesn’t work. One needs to create a separate policy with Action “Service Auth” (instead of “Allow”) and add there the Service Access Token.

I am not sure if someone of CF is reading this, yet if that’s intended then maybe it would be a good idea to remove “Service Access Token” when “Allow” is configured, as those seem to be incompatible.

2 Likes
5

Hi from the CF Access team,

This is good feedback, we could definitely make the differences between Allow and Service Auth more clear. I’ll chat with our documentation team about this.

That being said, a Service Token is still a valid option for an “Allow” policy. It can be checked as part of a user’s authentication if you want an added layer of security. The issue here is that the Allow policy was triggering a 302 redirect to the Access login page which an API can’t do anything with.

6

Hmm If that’s the case then I am wondering why a regular user could login. If both conditions are “AND” (not OR as I assumed) then I’d suspect that a user would also not fulfill the criteria of having the Service Access Token.

7

Include’s function as OR’s which is why a user would get let through there. More detail: Access policies · Cloudflare Zero Trust docs

If you wanted to explicitly enforce Service Tokens for users, you’d want to make it a Require rule.

8

I am sorry, but you lost me … How can a Service Token with “Allow” then be used. As you said yourself the user was redirected to the login page even so the Service token was specified as header. That doesn’t really make sense.

That “if you want an added layer of security” also doesn’t make sense, as you said now that the configuration is “OR” as assumed, so its not an “additional” condition that needs to be met.
Maybe you meant that an Auth Token can be used as a “Require rule”. I totally give you that, but not as an “Include rule”.

So I’d stick with my point that Auth Token should not be an option as “Include Rule” if someone specifies Action “Allow”

9

Fair point, re: “added layer of security”. :+1:

We try to keep policy option availability as broad as possible to avoid limiting users trying to accomplish something specific. There are still valid, though uncommon, configurations where Including a Service Token in an Allow policy is valid.

You could do something like:

Include = Service Token
Require = IdP - Okta

This would only allow a user to reach the Access authentication page if they had a service token present in their request headers.

10

Understood and I agree that an “Allow” policy of this nature might work:

The thing that I wanted to advocate for was that this one doesn’t do anything meaningful and the Service Token is ignored:

Require = Service Token
Require = IdP - Okta

11

You saved my day! I had been trying for hours. Thank you very much!