…oic425)

This PR was merged into the 1.10-dev branch.

Discussion
----------

| Q               | A
| --------------- | -----
| Branch?         | 1.7, 1.8 or master <!-- see the comment below -->
| Bug fix?        | no/yes
| New feature?    | no/yes
| BC breaks?      | no/yes
| Deprecations?   | no/yes <!-- don't forget to update the UPGRADE-*.md file -->
| Related tickets | fixes #X, partially #Y, mentioned in #Z
| License         | MIT

<!--
 - Bug fixes must be submitted against the 1.7 or 1.8 branch (the lowest possible)
 - Features and deprecations must be submitted against the master branch
 - Make sure that the correct base branch is set

 To be sure you are not breaking any Backward Compatibilities, check the documentation:
 https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->

When using a SSO such as Keycloak, you don't need a password. It's better to allow null instead of setting plain password with a random value.

Moreover, password will be decoupled from user interface on Symfony security user.
symfony/symfony#40267



Commits
-------

e20f871 Allow user password to be null
9daecf6 Move migration into core bundle

…oic425)

This PR was merged into the 1.10-dev branch.

Discussion
----------

| Q               | A
| --------------- | -----
| Branch?         | 1.7, 1.8 or master <!-- see the comment below -->
| Bug fix?        | no/yes
| New feature?    | no/yes
| BC breaks?      | no/yes
| Deprecations?   | no/yes <!-- don't forget to update the UPGRADE-*.md file -->
| Related tickets | fixes #X, partially #Y, mentioned in #Z
| License         | MIT

<!--
 - Bug fixes must be submitted against the 1.7 or 1.8 branch (the lowest possible)
 - Features and deprecations must be submitted against the master branch
 - Make sure that the correct base branch is set

 To be sure you are not breaking any Backward Compatibilities, check the documentation:
 https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->

When using a SSO such as Keycloak, you don't need a password. It's better to allow null instead of setting plain password with a random value.

Moreover, password will be decoupled from user interface on Symfony security user.
symfony/symfony#40267



Commits
-------

e20f871d9a49c6028ba7c1cd3708f7986ebe32aa Allow user password to be null
9daecf696b3c489dbe56f7ba26b162527a7948c9 Move migration into core bundle

…serIdentifier() (wouterj)

This PR was squashed before being merged into the 5.3-dev branch.

Discussion
----------

[Security] Rename UserInterface::getUsername() to getUserIdentifier()

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | yes
| Tickets       | Fix part of #39308
| License       | MIT
| Doc PR        | tbd

This continues the great work by @chalasr in #40267 and rounds up the `UserInterface` cleanup.

The `getUsername()` has been a point of confusion for many years. In today's applications, many domains no longer have a username, but instead rely on a user's email address or the like. Even more, this username has to be unique for all Security functionality to work correctly - so it's more confusing in complex applications relying on e.g. "username+company" to be unique.

**This PR proposes to rename the method to `getUserIdentifier()`**, to more clearly indicate the goal of the method (note: I'm open for any other suggestion).

For BC, the `getUsername()` method is deprecated in 5.3 and `getUserIdentifier()` will be added to the `UserInterface` in 6.0. PHPdocs are used to improve type-hinting for 5.3 & 5.4. Both authentication managers (the legacy and experimental one) check the authenticated user object and trigger a deprecation if `getUserIdentifier()` is not implemented.
* [x] **judge whether we need to have better deprecations for calling `getUsername()` in the application code.**

Consistent with these changes, I've also done the same BC change for `TokenInterface::getUsername()`.
* [x] **do the same for remember me's `PersistentTokenInterface::getUsername()`**
* [x] **also rename `UserProviderInterface::loadUserByUsername()` & `UsernameNotFoundException`**
* [x] **also rename `UserLoaderInterface::loadUserByUsername()`**

I'm very much looking forward for feedback and help for this important, but BC-heavy, rename. 😃

Commits
-------

8afd7a3 [Security] Rename UserInterface::getUsername() to getUserIdentifier()

…dUserInterface (jrushlow)

This PR was squashed before being merged into the 1.0-dev branch.

Discussion
----------

[make:user] user entities implement PasswordAuthenticatedUserInterface

Starting in Symfony 5.3 - PR symfony/symfony#40267 introduces the new `PasswordAuthenticatedUserInterface` ~& `LegacyPasswordAuthenticatedUserInterface`~ aimed at decoupling passwords from the `UserInterface`.

- Generated `User` entity implements `PasswordAuthenticatedUserInterface` if it exists.
- Adds correct type hint to the generated `UserRepository::upgradePassword()` method.

Authentication related changes are handled in #824

// cc @chalasr

Commits
-------

f9d9d03 [make:user] user entities implement PasswordAuthenticatedUserInterface

…rInterface (chalasr)

This PR was merged into the 6.0 branch.

Discussion
----------

[Security] Remove getPassword() and getSalt() from UserInterface

| Q             | A
| ------------- | ---
| Branch?       | 6.0
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

with BC layers from #40267

Commits
-------

30e2c00 [Security] Remove getPassword() and getSalt() from UserInterface