auto_redirect_to_identity is not working anymore - 2

[PimSijm]

Hi Chris,

A while ago i've opened an issue about redirecting to identity (issue 139). You've managed to fix it then but the issue is back again since v3.0.3 and migration to access groups.
No matter what I try, it's just not working and i keep getting the IDP-selection page first. Can you look into it please?

Thanks!

Example Docker labels used:
labels:
- dockflare.enable=true
- dockflare.access.auto_redirect_to_identity=true
- dockflare.access.policy=authenticate
- dockflare.access.allowed_idps=xxxxx-yyyyyy-zzzzzz
- dockflare.hostname=bazarr.example.com
- dockflare.service=http://Bazarr:6767
- dockflare.access.groups=AG-Group-1,AG-Group-2

[ChrispyBacon-dev]

I already have a suspicion indeed there were some changes that broke other things that I had to fix as well. I look into it.

Cheers, Chris

[ChrispyBacon-dev]

Hi there,

ok I found some time,,, I had a very busy week sorry for the delay my day job is currently really demanding towards the end of year.

Here’s the short version of what’s happening:

Why the auto_redirect_to_identity label no longer works as before

Since v3.0.3, DockFlare uses the Reusable Policy Architecture, where Access Groups are now the main way to define and manage access settings.
When a container is linked to an Access Group via the dockflare.access.groups label, the group’s configuration takes full precedence.

Because of this, container-specific access labels like dockflare.access.auto_redirect_to_identity are intentionally ignored once an Access Group is assigned. This helps keep policy behavior consistent and centralized.

In your setup, the redirect behavior depends entirely on the configuration of AG-Group-1 and AG-Group-2. If “Auto Redirect to Identity” isn’t enabled within those groups, it defaults to false.

How to fix it

The intended way to enable redirect is directly in the Access Group:

1. Open your DockFlare UI.

2. Go to Access Groups.

3. Edit AG-Group-1 (and AG-Group-2 if applicable).

4. Enable Auto Redirect to Identity.

5. Save the changes.

Once updated, Dockflare/Cloudflare will apply this setting automatically, and as this is the cool thing with reusable access policies, therefore to all containers linked to those groups.

I hope that clarifies why the label stopped working and how to get the behavior you expect again.
The auto_redirect_to_identity label itself was overlooked during the refactoring from the legacy access policy rule creation to the new reusable access policy logic. I’m not yet sure if I’ll reintroduce logic to support it again, or leave it as-is since the same behavior can now be controlled through the reusable policy settings in the web UI.

Cheers,
Lieben Gruss,
Chris

[PimSijm]

Hi Chris,

Thanks for getting back to me on this.

Unfortunately i was afraid this would be the issue. I'm using "external" policies since I'd rather use "Rule Groups" from within Cloudflare to have a more granular control over everything. Also, you do have the option to block countries in your access policies but I find it much cleaner to use an allow list since I only want to allow The Netherlands and Sweden. I know it's possible to select all and invert but it feels just not right. It would also mean that if I go abroad I need to change all access policies.
To circumvent this issue the Cloudflare Rule Groups are amazing since you can use them nested within each other.

If you would be able to create/sync/user the rule groups from Cloudflare and be able to manage those in your access policies then I think it will all work out very nicely!

If you would like some screenshots i'm happy to provide them. Please reach out to me with a PM for this so I don't have to redact all of it.

Pim

[ChrispyBacon-dev]

if you don't mind, how do you create an access policy with allow these two countries?

[PimSijm]

I've got the following Rule Groups:

1. Countries

• Include:
  Country: Netherlands & Sweden

2. Internal

• Include:
  IP ranges: w.x.y.z/32 (my own external IP)

3. MFA

• Include:
  Emails:
• Require:
  Login Methods: (in my case Azure AD)
  Rule group: Countries (so this is rule group 1 as mentioned above).

Rule Group 3 provides that the user with my e-mail address can have access but requires MFA through Azure AD AND needs to be in 1 of 2 countries. If another user needs access it can be provided through another Include since this is the OR selector.

Then there's 3 types of Policies:

1. Bypass-Countries: (This allows for public acces to certain apps without authentication as long as they are access from 1 of 2 countries. For example NextCloud since the apps need to work and MFA is provided through NextCloud.

• Type: BYPASS
• Include:
  Rule group: Countries

2. Bypass-Internal: (This allows for most apps to be accessed from my own connection without MFA since this is a trusted location.

• Type: BYPASS
• Include:
  Rule group: Internal

3. Allow-MFA: (This allows for access to apps which require MFA)

• Type: ALLOW
• Include:
  Rule group: MFA

This setup provides the ability to change just the Countries Rule Group to have access to all applications without editing all of them.

One more thing now that I think about it.
I've created an Access Policy through DockFlare and set Azure AD as IDP, put in my e-mail address and blocked all countries except The Netherlands and Sweden but it's flawed within CloudFlare and is something that needs some quick fixing on your end. Both the e-mail address and the login method (Azure AD) are used as "Include". The "Included" in CloudFlare are "OR" selectors so now it's either my e-mail address OR Azure AD login that's granted access, not the combination of both. I think it would be best to put the e-mail as "Include" and the Login Methods as "Required" ("Required" is an "AND" within CloudFlare).

If you can't sync the Rule Groups then i guess it would be best to set the allowed countries are "Required" as well instead of "Exclude" for the blocked ones.

Hope this info is useful!

PS: Thanks for all of your hard work on this project. I think it's one of the coolest and most useful i've seen in a long time. Hope you can keep it up!!!

[ChrispyBacon-dev]

currently traveling so just a quick feedback about access policies great feedback, this reminds me of this issue

#261

On the official CloudFlare documentation, the process of setting up an access policy with an Identity Provider (IDP) involves the following steps:

1. Set up the Login Method as “IDP.”
2. Include a selector for your “email addresses” that are enrolled with the IDP but not required unless you opt for email-onetime PIN.

However if you want to use just email address with Onetime PIN (Cloudflare is sending a PIN to email) than you use require email "john.smith@company.com"

Everybody can chime in and correct me if I'm wrong about this.

https://developers.cloudflare.com/cloudflare-one/access-controls/policies/#bypass

great exchange I love this.

Cheers,
Chris

[PimSijm]

It's a bit confusing i guess but if you scroll down to Rule Types (https://developers.cloudflare.com/cloudflare-one/access-controls/policies/#rule-types) there is a good explanation about how it works ;)

[PimSijm]

Hi Chris,

Did you happen to been able to look into this? If i can help in any way, please let me know!
Have a good weekend!