[Security] Removed anonymous in the new security system

[wouterj]

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	-
License	MIT
Doc PR	tbd

This was one of the "Future considerations" of #33558:

Drop the AnonymousToken and AnonymousAuthenticator: Anonymous authentication has never made much sense and complicates things (e.g. the user can be a string). For access control, an anonymous user has the same meaning as an un-authenticated one (null). This require changes in the AccessListener and AuthorizationChecker and probably also a new Security attribute (to replace IS_AUTHENTICATED_ANONYMOUSLY). Related issues: #34909, #30609

This new experimental system is probably a once-in-a-lifetime change to make this change. @weaverryan and I have had some brainstorming about this. Some reasons why we think it makes 100% sense to do this change:

• From a Security perspective, a user that is not authenticated is similar to an "unknown" user: They both have no rights at all.

• The higher level consequences of the AnonymousToken are confusing and inconsistent:

  • It's hard to explain people new to Symfony Security that not being logged in still means you're authenticated within the Symfony app
  • To counter this, some higher level APIs explicitly mark anonymous tokens as not being authenticated, see e.g. the is_authenticated() expression language function
  • The anonymous authentication resulted in the IS_AUTHENTICATED security attribute being removed from [Security] Use new IS_* attributes in the expression language functions #35854, as there was no clear consensus on what its meaning should be

• Spring Security, which is where this originated from, makes Anonymous a very special case:

  Finally, there is an AnonymousAuthenticationFilter, which is chained after the normal authentication mechanisms and automatically adds an AnonymousAuthenticationToken to the SecurityContextHolder if there is no existing Authentication held there.

  Note that there is no real conceptual difference between a user who is “anonymously authenticated” and an unauthenticated user. Spring Security's anonymous authentication just gives you a more convenient way to configure your access-control attributes. Calls to servlet API calls such as getCallerPrincipal, for example, will still return null even though there is actually an anonymous authentication object in the SecurityContextHolder.

• Symfony uses AnonymousToken much more than "just for convience in access-control attributes". Removing anonymous tokens allows us to move towards only allowing UserInterface users: [Security] deprecate non UserInterface users #34909

---

Removing anonymous tokens do have an impact on AccessListener and AuthorizationChecker. These currently throw an exception if there is no token in the storage, instead of treating them like "unknown users" (i.e. no roles). See #30609 on a RFC about removing this exception. We can also see e.g. the Twig is_granted() function explicitly catching this exception.

• To make the changes in AccessListener and AuthorizationChecker BC, a flag has been added - default enabled - to throw an exception when no token is present (which is automatically disabled when the new system is used). In Symfony 5.4 (or whenever the new system is no longer experimental), we can deprecate this flag and in 6.0 we can never throw the exception anymore.
• anonymous: lazy has been deprecated in favor of { anonymous: true, lazy: true } This fixes the dependency on AnonymousFactory from the SecurityExtension and allows removing the anonymous option.
• Introduced PUBLIC_ACCESS Security attribute as alternative of IS_AUTHENTICATED_ANONYMOUSLY. Both work in the new system, the latter only triggers a deprecation notice (but may be usefull to allow switching back and forth between old and new system).

cc @javiereguiluz you might be interested, as I recently talked with you about this topic

[simonberger]

I really like this change. The anonymous part of the authentication process was always troublesome to handle. Your changes in #30914 are generally much appreciated.

[javiereguiluz]

I don't understand the internals of this ... but are we going to keep this IS_AUTHENTICATED_ANONYMOUSLYpermission? I hope we can get rid of everything about "anonymous + authenticated".

[weaverryan]

There DOES still need to be something like this, as it’s used when you are “whitelisting” paths in access_control. But it doesn’t need to have this name... though changing the name could be done later - that may simplify things.

[wouterj]

We indeed need an attribute to whitelist pages that are within the firewall, but accessible for unauthenticated users (e.g. the login page).

A couple suggestions after a chat about this:

1. PUBLIC_ACCESS
2. ALLOW_ACCESS_TO_ALL
3. NO_SECURITY

Do you, @javiereguiluz, or someone else favor one of these options (or another suggestion)?

[simonberger]

Also that we want to get rid of anonymous authentication the trigger word anonymous is still very good to describe an unprotected access. So another option could be ANONYMOUS_ACCESS in this context.

[javiereguiluz]

Random idea ... add a exclude option for access_control entries:

access_control:
    - { path: '^/admin/users', roles: ROLE_SUPER_ADMIN }
    - { path: '^/admin', roles: ROLE_ADMIN, exclude: ['^/admin/login', '^/admin/public/*'] }

[wouterj]

Thanks for thinking outside the box @javiereguiluz! I'm not totally sure if this would make things much clearer, given the access control is already a list of patterns. Having a sub-list of excluded pattern for each pattern might make it more confusing to see which rule is used for which request. Maybe we have to completely revisit the access control configuration in another version of Symfony 😄

I've updated the PR to use PUBLIC_ACCESS. Using anonymous is correct, it's maybe best to (at least for the next versions) avoid that term to remove confusion. Also, any logged in user is not accessing such a page "anonymously".

[javiereguiluz]

@wouterj thanks for this 🙇 Trying to explain that "anonymous users" are "authenticated" was one of the most WTF moments in Symfony training. It never made sense to anyone. So glad to get rid of this.

[wouterj]

This PR is now tested in the Symfony Demo application and works like charm 🎉 . I've updated the PR description with the current state. Ready for review & merge imho.

---

I managed to break fabbot's exception message format and I'm unable to fix the error using concatenation 😢 The other build failures are also unrelated.

[fabpot]

Thank you @wouterj.

[kappa1389]

If token is not provided in request and no access control is defined for called route then firewall gets bypassed, but the expected behavior is to get an authentication exception with code of 401
I face this problem with new symfony security integrated with lexik
Any ideas?

[derrabus]

Hello @kappa1389 and thank you for reaching out.

This tracker is meant for tracking bugs and feature requests. If you are looking for support, you'll get faster responses by using one of our official support channels:

• StackOverflow: https://stackoverflow.com/questions/tagged/symfony
• Slack: https://symfony.com/slack

See https://symfony.com/support for more support options.

[kappa1389]

Dear Alexander Thank you for your reply i will take it into account Best regards

…

On Tuesday, August 3, 2021, Alexander M. Turek ***@***.***> wrote: Hello @kappa1389 <https://github.com/kappa1389> and thank you for reaching out. This tracker is meant for tracking bugs and feature requests. If you are looking for support, you'll get faster responses by using one of our official support channels: - StackOverflow: https://stackoverflow.com/questions/tagged/symfony - Slack: https://symfony.com/slack See https://symfony.com/support for more support options. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36574 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVAFHYD6YCTTJZR3I4KH7XLT26Q3TANCNFSM4MQNG6OA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .