Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] Symfony Security rework tracking issue #30914
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 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:
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
This was referenced
Apr 6, 2019
referenced this issue
Apr 7, 2019
Following your comment on #28868, I wanted to add what I wrote there about authentication.
The current implementation considers authentication as a binary state (authenticated / not authenticated), and we use additional roles and rules (IS_AUTHENTICATED_FULLY) to determine the amount of trust we give to the authenticated principal.
The main issue is that we use authorization to describe something purely related to authentication. Something interesting could be to change this idea of binary status and replace it with a level of trust (e.g. an authentication through a form_login gives you 100 points). Having a 2FA form / using the remember me feature / having multiple factors could have an impact on this level of trust (e.g. using login_form + 2fa gives you a total of 150 points, using remember me gives you a total of 80 points, ...).
We could use this mecanism to ease authentication controls by defining, for instance, a minimal level of trust either using firewalls or path based security rules. This would give a lot of flexibility to craft advanced authentication mecanisms.
@quentinus95 interesting thoughts. You should however remember that the process of authentication itself is handled by Tokens, so the process of how an authentication chain ends up at a certain level of trust should be handled there. This is even already being improved by the proposal at #30765.
In a nutshell right now we're pretty limited with the RememberMeToken granting
Updated RFC with some minor things:
@curry684 , this is a great list, thank you!
I have some thoughts: