Cloudflare Access Beta Feedback

beta
access

#1

Hello!

Today we are launching a very limited beta for a new feature called Cloudflare Access. If you are interested in participating you can submit a request on this form.

We’re excited to get your thoughts and ideas about Cloudflare Access. Let us know what you think - both good and bad, and how you end up using the product. Looking forward to hearing from you.

-Dani

Update 10/23/17:

You can now join the Access beta at cloudflare.com/a/access/


Access (Setup & Usage)
#2

An authentication domain cannot be added for each domain? current authentication domain affects all domains


#3

Yes. The reason for this is to make it easy to add domains to Edge Auth. A new set of keys for each identity provider needs to be generated for each authentication domain so by keeping it standard across domains, you only need to generate keys once.


#4

Love the idea behind this. Currently, my only use case would be to lock down a specific path and not a full domain.

I’d use it on my wordpress sites such as “/wp-admin/” and other “/admin/” areas I have on other sites.


#5

Very cool, thanks @alexphelps3! We’ve been exploring adding path support - then you could use it to send specific files to someone as well.


#6

Okay so, some basic testing completed using GitHub as my OAuth authentication source.

Pros:

  • It’s super easy to setup, I got it working in less than 5 minutes
  • Once working it’s a really clean experience from the user perspective - i.e. even my mother could figure out that they click the ‘login with X button’ to get access

Cons:

  • Although the login page looks relatively ‘whitelabel’ the main issue I have is that the user is taken away from your actual domain to the blah-example.cloudflareauth.com domain, somewhat breaking the trust a user could have in your application/website. I’m not sure if this is merely a feature of the BETA and that Pro/Business/Enterprise users will be able to have the authentication page on their own domain, or an actual current technical limitation in the feature itself.
  • None really, I can’t actually fault it other than needing to embed your app to get a log-out/de-auth button. It works as expected but I’m sure there are still plenty of edge cases that I can’t think of covering.

#7

@kawaii that’s great feedback! We’re going to let you swap out the logo so that it’s your logo on the authentication page. Are there other customizations you would want to make?


#8

It would be nice to be able to specify the duration a user stays authenticated for (i.e. 1 hour, 6 hours etc…) before needing to re-authenticate with the chosen oAuth provider. That’s all I can think of right now, but I’ll be sure to come back and mention any other ideas I might get. :slight_smile:


#9

@kawaii great idea! we are very likely to add that soon. we are thinking to do 6 hrs, 12 hrs, 1 day, 1 week, 1 month options.


#10

This is cool, especially for someone like me who lock domain names and directories with Htaccess + Htpasswd.

-Though i used Github as my identity provider for Edge contrary to my Htaccess method which allow me easily list all authorized user email and passwords.
I think it would be nice to have such ability with Edge, and not just using Github, Facebook e.t.c

-As if the inability to use my domain name as the authentication domain isn’t enough, having to use just a single authentication domain for all websites under my account doesn’t seem cool either.
For Domain1, I could have something1.cloudflareauth.com
For Domain2, I could decide to have something2.cloudflareauth.com

-When a user is currently logged in and i remove such user from the View Access list, it should destroy the current session and log the user out.

-Won’t be bad to also have list of url link a specific user visits and time of access.

So far, it’s sure a nice idea. Good job


#11

@A-J Thanks so much for all of your thoughts!

The auth domain per site - the reason why we have an auth domain across your entire account is because a new set of keys for each identity provider needs to be generated for each authentication domain. By keeping it standard across domains, you only need to generate keys once.

The session should be ended - 100%, we will fix.

“Won’t be bad to also have list of url link a specific user visits and time of access.” – good idea.


#14

We’re in the process of trying to setup oAuth across all of our clients. This would save that work.
However, we would need each domain to have their own Access settings, not something set for all accounts.

I would guess that any service that has separate instances per customer is going to have a similar problem.


#15

I’m hitting a “There was a problem logging you in.” message after clicking on the Log in via Google Apps button and completing the Google Apps login steps. Where can I go to dig into the error a bit more?

Is this the correct place to post this type of question?


#16

@TRIBUS that’s useful!

Each domain has its own Access policies. When you create an Access policy, it is only for that domain.

We do share the Login Domain (what visitors see as the URL in the browser when they visit your application) across the domains in your account so that you do not need to setup a new identity provider connection for each domain.

Does that fit what you are trying to do?


#17

@user275 We would love to help you debug. Can you send me a screenshot and let me know which domain this happens on at [email protected]?


#18

@dani I think we would have to setup a different identity provider for each domain since each Google Apps domain is going to require a separate one - no?

Unless you have another idea?

Also can I suggest adding Office 365 - a huge number of enterprises are on that.


#19

Hey @TRIBUS - We’re really open to feedback on this. Right now the thought is that you can reuse identity providers across all your domains. That way even if you have 100 domains that all run different internal tools, you don’t need to create 100 connections to GSuite or whichever identity provider you use. Let us know what you think.

Office365 – yes, stay tuned.


#20

Some feedback/thoughts related to UI:

  • Adding Identity Provider: Provide clickable links to e.g. Google Cloud Console when adding Google oAuth - similar for Facebook and Okta
  • Access Setup Wizard: Be able to rename the CF-Access subdomain before adding first identity provider (in case of any typo or so)
  • Access Tab: Each time reloading the site the setup wizard of “CF Access” switches visible through the creation process (looks a bit strange.)
  • Changing CF-access url: When changing the CF-Access subdomain any warning that existing callback urls have to be changed as well would be probably a nice hint for some users
  • Portal Customization: When changing colors of login page hex codes without leading “#” should be accepted (easier for copy&pasting)
  • Log Viewer: On any logged actions the exact time isn’t visible as it’s being truncated like: “12 minutes…” (missing “ago” at the end)

So far everything is working fine, tried Facebook authentication so far. The Setup Wizard, the UI, is quite simple and understandable, but I’m missing some further explanation or guide after the basic configuration is done: when setting up “Access Policies”.

  • Application Domain: I need to enter a owned subdomain. What about a autocomplete functionality to suggest some subdomains from the DNS view? Furthermore it shouldn’t be possible to enter any URLs instead of just domains to prevent false input.
  • Session Duration: Wouldn’t be “1h hour” also possible?
  • Revoke Existing Tokens: Can I revoke specific tokens/user permissions instead of everyone?
  • Property: Regarding this selection I’d suggest making it clearer what input is expected here. For example “Property: Group”. Which kind of group? Google Groups? Facebook Groups? ID or its name? Same with “GitHub Organization”.

One more point:

  • Feature Request: Being able to protect particular addresses/folders instead of just (sub)domain. I’ve something like Wordpress Admin Area in mind. Entering any URL is possible, but just not working.

I hope my feedback is kind of useful. Very cool and useful feature! :slight_smile:


#21

Hello,
I found a bug when I tried to access https://www.cloudflare.com/a/access/
It told me to enter a text field that show “domain1.cloudflareapp.com” something like that so I switched to check my another domain if this beta access available in 2nd domain but I see now it need me to create first identity provider same happen to the first domain which that text field gone. is that normal ?
Thanks


#22

@dani being that each domain requires a different key though for at least Google / G Suite, and that each client runs their own GSuite etc authentication.

Perhaps a setting that would allow you to say which sites you’d want to use it on?