This PR was merged into the 5.1-dev branch.Discussion----------[Security] Fix missing nullable in CsrfTokenBadge| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | yes| New feature?  | no| Deprecations? | no| Tickets       || License       | MIT| Doc PR        |Related to#33558 I noticed a minor 🤏  bug with the method return-type.Commits-------5cb633c Update CsrfTokenBadge.php

…wouterj)This PR was merged into the 5.1-dev branch.Discussion----------[Security] Apply left-over review comments from#33558| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| Deprecations? | no| Tickets       | -| License       | MIT| Doc PR        | n/aThis applies the review comments of@noniagriconomie in#33558. It's mostly doc fixes and one extra security-safeguard by resetting the plaintext password early (similair to what is done in `PasswordCredentials`).Commits-------be3a9a9 Applied left-over review comments from#33558

…ultiple authenticators (wouterj)This PR was squashed before being merged into the 5.1-dev branch.Discussion----------[Security] Require entry_point to be configured with multiple authenticators| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| Deprecations? | no| Tickets       | -| License       | MIT| Doc PR        | tbdSee@weaverryan's comment at#33558 (comment):> I have it on my list to look at the entrypoint stuff more closely. But my gut reaction is this: let's fix them (or try to... or maybe in a PR after this) :). What I mean is this:>> -    It's always been confusing that your firewall may have multiple auth mechanisms that have their own "entry point"... and one is chosen seemingly at random :). I know it's not random, but why does the entrypoint from `form_login` "win" over `http_basic` if I have both defined under my firewall?>> -    Since we're moving to a new system, why not throw an exception the _moment_ that a firewall has multiple entrypoints available to it. Then we _force_ the user to choose the _one_ entrypoint that should be used.---**Before** (one authenticator)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      form_login: ...# form login is your entry point```**After**Same as before---**Before** (multiple authenticators)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...# for some reason, FormLogin is now your entry point! (config order doesn't matter)```**After**```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...      entry_point: form_login```---**Before** (custom entry point service)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...      entry_point: App\Security\CustomEntryPoint```**After**Same as beforeCommits-------7e86169 [Security] Require entry_point to be configured with multiple authenticators

…ultiple authenticators (wouterj)This PR was squashed before being merged into the 5.1-dev branch.Discussion----------[Security] Require entry_point to be configured with multiple authenticators| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| Deprecations? | no| Tickets       | -| License       | MIT| Doc PR        | tbdSee@weaverryan's comment atsymfony/symfony#33558 (comment):> I have it on my list to look at the entrypoint stuff more closely. But my gut reaction is this: let's fix them (or try to... or maybe in a PR after this) :). What I mean is this:>> -    It's always been confusing that your firewall may have multiple auth mechanisms that have their own "entry point"... and one is chosen seemingly at random :). I know it's not random, but why does the entrypoint from `form_login` "win" over `http_basic` if I have both defined under my firewall?>> -    Since we're moving to a new system, why not throw an exception the _moment_ that a firewall has multiple entrypoints available to it. Then we _force_ the user to choose the _one_ entrypoint that should be used.---**Before** (one authenticator)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      form_login: ...# form login is your entry point```**After**Same as before---**Before** (multiple authenticators)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...# for some reason, FormLogin is now your entry point! (config order doesn't matter)```**After**```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...      entry_point: form_login```---**Before** (custom entry point service)```yamlsecurity:  enable_authenticator_manager: true  firewalls:    main:      http_basic: ...      form_login: ...      entry_point: App\Security\CustomEntryPoint```**After**Same as beforeCommits-------7e861698e7 [Security] Require entry_point to be configured with multiple authenticators

…m (wouterj)This PR was merged into the 5.1-dev branch.Discussion----------[Security] Removed anonymous in the new security system| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Tickets       | -| License       | MIT| Doc PR        | tbdThis 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,#30609This 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](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Authorization/ExpressionLanguageProvider.php#L33-L37)  * The anonymous authentication resulted in the `IS_AUTHENTICATED` security attribute being removed from#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**:#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](https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Extension/SecurityExtension.php#L37-L52).* **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 topicCommits-------ac84a6c Removed AnonymousToken from the authenticator system