Open jzheaux opened 2 years ago
For now, I'm taking off the 5.8.x
milestone, pending the team's upcoming 5.8 planning meeting.
Sorry I wasn't clear when we met what I was looking for. Let's leave this on 5.8.s as you had very valid reasons for us needing to include it. Specifically we will be deprecating the old RunAsManager behavior without a replacement for users to migrate to before moving to Security 6.0. This fits into our theme of deprecations for 5.x and ensuring we provide a way to opt into their replacements before 6.0x to ease migrations.
Any hints to how one should proceed if wanting to implement impersonation and/or privilege escalation with Spring Security 6?
Can you update the doc too? https://docs.spring.io/spring-security/reference/servlet/authentication/runas.html
It's disappoint others when read doc then found out it's already a deprecated feature. https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/access/intercept/RunAsManager.html
Any progress on this?
RunAsManager
can add to or change the existing authentication for the duration of a message, a request, or a method call.It overloads the authority string to include instructions to Spring Security as to what authorities to temporarily grant. It is primarily designed to work with the
@Secured
annotation and with theaccess
XML attribute when not using expressions.As a first step to supporting this with the authorization manager API, we should:
ImproveAuthorizationFilterParser
to supportuse-expressions="false"
ImproveAuthorizationFilterParser
to adapt theSupplier<Authentication>
forRUN_AS
attributesImprove@Secured
method handling to adapt theSupplier<Authentication>
forRUN_AS
attributesUPDATE: Let's wait on these subtasks. This isn't the way that we want to do impersonation and privilege escalation going forward, and so I don't really want to support a legacy way in a new API. I'll leave this ticket open for investigating what this support should look like going forward.
It's worth considering whether a new contract is needed like
Supplier<Authentication> adapt(Supplier<Authentication> authentication, T context)
that can be supplied to alter how the adaptation is performed.