After discussions at EU FOSSA Hackathon we have some ideas on how to rework the Security component. I'm writing this "tracker issue" to gather up the info and choices made thus far.

The biggest functional issues have been discussed frequently over the years (#10316 and others) that the authentication makes some shortcut assumptions no longer valid in 2019:

• The object of security considerations is not always a user, it may be a device, a computer, an API key, or any number of other abstract things. In the security world the concept of "something that can participate in security questions" is called a Principal.
• There should be a functional separation between the Principal performing an action and the Context he is in while doing so. Authorization decisions should be based on the presented Context. This solves many practical issues like impersonation and "act as company".
• Principals may be authenticated by various means, and be oblivious themselves on the subject. Principals should therefore not expose functionality to get passwords or roles as they may not have any. Tokens handle authentication.

The Symfony Security component was originally based on the Java Spring Security framework, but has deviated over the years. Today Spring Security has both fixed some structural issues that Symfony has (the notion of principals versus users and no central assumption that passwords and roles exist) and has some features that are currently lacking or hacky at best (structural support for OpenID/OAuth, support for 2FA). Conclusion for now is that most of the current Security component, especially authorization, is mostly fine and does not need a lot of work, and it wouldn't be all that hard to fix the authentication parts, and more strongly decouple authentication and authorization, by taking some current inspiration from Spring again.

Once these changes are propagated a lot of other features related to authentication should be easier to implement. Wishlists have been assembled:

Authentication

• User impersonation (including multiple impersonation without having to log out) not affected by Security changes
• Social login (login in the app using Google, Facebook, GitHub, Twitter, etc.) and generic OAuth support ([WIP][Security] OAuth2 component #31952 (comment))
• Login throttling (limit the number of failed login attempts over a period of time)
• Simultaneous session limiting (e.g. each user can login only from one device at the same time)
• Two-factor (or multi-factor) authentication ([Security] Native support for 2FA #28868 (comment))
• “Sudo mode” (trigger a new authentication before sensitive operations, like GitHub) ([Security] Add "sudo mode" #33955)
• Native JWT implementation if some package is available (firebase/php-jwt ?)
• CSRF on router level
• User checkers (allow to make checks after user has logged in to block the log in if needed)
• LDAP (authenticate against a LDAP server) not affected by Security changes
• Support for third-party authentication services (e.g. Auth0: https://auth0.com/)
• Support for SAML 2.0 (authentication and federation mechanism)
• Support pre-authentication mechanisms (e.g. X.509 certificates, Request-Header authentication, etc.)
• Have a centralized token invalidation mechanism ([RFC] Symfony Security rework tracking issue #30914 (comment)) ([Security] Rework the remember me system #40145)
• Easy to add new authentication mechanisms (as Guard currently offers)
• Easy customization of provided authentication mechanisms (especially form_login, which is the most complex and most used one): through events/hooks? Or implement those as Guards, we can easily decorate/override?
• More events: at least having an event before a login is attempted, which could be used to implement custom rate-limiting mechanism
• Constant timing user login for non-existent user (to protect leaking existence of a user) - see https://github.com/paragonie/airship/blob/8f04f071c414c3893cf66311839d20a343af1237/src/Engine/Security/Authentication.php#L161-L168 for technical details

Authorization

• "Access control" to set permissions over web site sections using regexps not affected by Security changes
• Native @Security annotation to set the permissions of controller classes and/or actions not affected by Security changes
• Grant or deny permissions based on trust levels, such as whether 2FA is enabled or "sudo mode" is required
• Having an opinionated way to set up object-level control mechanism (CRUD). Voters tend to be a little bit too general in my opinion, making necessary to set up per project conventions (ie, you have to check for “EDIT” attribute…), which can’t be enforced programmatically now.

Users

Dropping the notion of users at the lowest level must not mean DX suffers and developers need to write a lot of boilerplate again. In fact directly implementing PrincipalInterface should likely be considered an advanced subject, and we should provide a layer with abstract and stock implementation of common user-based scenarios:

• Allow to represent application users with a User class (bonus: help you create it with make:user). not affected by Security changes
• Allow to get a User object very easily from a Twig template. not affected by Security changes
• Allow to easily differentiate anonymous users and logged in users. ([Security] Removed anonymous in the new security system #36574 (comment))
• “Remember Me” feature (access to the app without having to log in again; and allow to differentiate those users from both anonymous users and users who logged in for real) ([Security] Rework the remember me system #40145)
• Roles (to have different kinds of users: normal users, admins, etc.) not affected by Security changes
• Allow to hash user passwords (Bcrypt, Argon2i, etc. but not old algorithms with custom salts) (
• Password rehashing (to upgrade from Bcrypt to Argon2i transparently) ([Security] Extract password hashing from security-core - with proper wording #39802)
• "I forgot my password" (implemented as make::reset-password)
• Email validation on registration (tracked in Verification system after registration maker-bundle#542)
• Allow to log in users programmatically in an easy way (e.g. $security->login(‘username’))
• Make it trivial to test protected resources (logging in a user in tests should be very easy)
• Password validators (check if password is too simple, if it has been compromised before, etc.)
• Have minimal requirements/assumptions about User class from Security component, so decoupling is easier (which is a pretty popular topic, actually). Only requiring username/password, likely? ([Security] Decouple passwords from UserInterface #40267)

Non-wishlist

• As we are committed to using voters for authorization, and do not want to have/support 2 mechanisms serving similar or mostly identical purposes we will not implement ACLs again

/cc @wouterj @derrabus @linaori @sstok