IBX-8356: Reworked Ibexa\Core\MVC\Symfony\Security\Authentication\AuthenticatorInterface usages to comply with Symfony-based authentication

[konradoboza]

🎫 Issue	IBX-8356

Related PRs:

• IBX-8356: Removed Ibexa\Core\MVC\Symfony\Security\Authentication\AuthenticatorInterface to be replaced with Symfony-based authentication core#375 (will be merged at the end, not blocking this part)
• IBX-8356: Reworked JWT firewall to be in-tact with the new Symfony auth recipes-dev#122

Description:

Reimplemented JWT authentication. The need for that comes from the fact, that Ibexa\Core\MVC\Symfony\Security\Authentication\AuthenticatorInterface relies on deprecated Symfony authorization mechanisms and will be dropped.

Reworked to be compliant with https://symfony.com/bundles/LexikJWTAuthenticationBundle/current/index.html#symfony-5-3-and-higher. The third-party provider has already moved to Symfony json_login authenticator so we are just adapting our implementation accordingly.

Few important changes:

• XML input is not supported from now on. Only Content-Type: application/vnd.ibexa.api.JWT+json header can still be used for keeping the whole solution BC safe, however the new authenticator should be referenced via Content-Type: application/json header instead,
• to make sure this is possible I added JsonLoginHeaderReplacingSubscriber which replaces mentioned header on the fly. I also left a TODO note to remember it should be dropped once the new REST API version is released. I am open for suggestions how to improve such reminder,
• I also removed SecurityListener and kind of replaced it with AuthenticationSuccessSubscriber - it sets current repository user on successful authentication and normalize the end response to be in-tact with the previous one (another BC-safe piece of code). The reason for that is that json_login handles the response outside and forms it similar to:

{
    "token" : "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXUyJ9.eyJleHAiOjE0MzQ3Mjc1MzYsInVzZXJuYW1lIjoia29ybGVvbiIsImlhdCI6IjE0MzQ2NDExMzYifQ.nh0L_wuJy6ZKIQWh6OrW5hdLkviTs1_bau2GqYdDCB0Yqy_RplkFghsuqMpsFls8zKEErdX5TYCOR7muX0aQvQxGQ4mpBkvMDhJ4-pE4ct2obeMTr_s4X8nC00rBYPofrOONUOR4utbzvbd4d2xT_tj4TdR_0tsr91Y7VskCRFnoXAnNT-qQb7ci7HIBTbutb9zVStOFejrb4aLbr7Fl4byeIEYgp2Gd7gY"
}

• I removed the whole logic from Ibexa\Rest\Server\Controller\JWT::createToken - all the heavy lifting is done by the json_login authenticator so it's not needed anymore. The whole controller was left though, as to my understanding it is needed for the route to be configured properly. If this is wrong, the whole class can just be dropped,
• I removed classes needed for input parsing and value object visiting since payload/response are formed differently as they become obsolete,
• src/lib/Security/AuthorizationHeaderRESTRequestMatcher.php was moved out of contracts and marked as @internal as we shouldn't allow manipulating with such vital part of the authentication process,
• I added test coverage to the introduced event subscribers,
• I improved the code quality in several classes by resolving outstanding PHPStan issues.

For QA:

Documentation:

We need to mention changes to payload, response and headers described above as much as removed/moved classes.

[Steveb-p]

I would need to know why the matcher specifically is being dropped, and what will be the new expected user configuration.

We used to use Matcher to allow firewalls to detect that they need to perform authorization in a specific way - and I assume that we are going to change it so that authentication mechanisms are no longer tied to firewalls like that. But I need to see the expected end result to judge.

[konradoboza]

I would need to know why the matcher specifically is being dropped

Can you please elaborate which matcher you have in mind? The configuration is tackled within https://github.com/ibexa/recipes-dev/pull/122/files.

[Steveb-p]

I would need to know why the matcher specifically is being dropped

Can you please elaborate which matcher you have in mind? The configuration is tackled within https://github.com/ibexa/recipes-dev/pull/122/files.

Ibexa\Rest\Security\AuthorizationHeaderRESTRequestMatcher (known before as Ibexa\Contracts\Rest\Security\AuthorizationHeaderRESTRequestMatcher). As @alongosz mentioned in his comments, if it's intended to be used in the configuration as a value, it has to remain in Contracts namespace.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[micszo]

Small suggestion for follow-up PR:

When using unsupported XML format error description could be more user friendly.
Now it states: "You must provide a ValueObject for visiting, "NULL" provided."

[Steveb-p]

Small suggestion for follow-up PR:

When using unsupported XML format error description could be more user friendly. Now it states: "You must provide a ValueObject for visiting, "NULL" provided."

It's something we might address when swapping over to Symfony Serializer for request parsing. Our current Visitors are barely performing sanity checks at all, and that error sounds more like something PHP would spew on it's own.