Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@nacorp friendly ping 😉

That's a cool update of the CAS authenticator @erseco ! 👏

OIDC handlers create a OidcUser from data equivalent to the ones this change gets from the CAS2 success response, do we need such user object here? Just wondering, it's fine if we don't.

@chalasr Thanks for your question!

Regarding whether we need a specific user object like OidcUser, I don't think it's necessary in this case.

According to the [CAS protocol specification](https://apereo.github.io/cas/7.0.x/protocol/CAS-Protocol-Specification.html#257-example-response-with-custom-attributes), CAS attributes are included directly in the XML/JSON response:

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
  <cas:authenticationSuccess>
    <cas:user>username</cas:user>
    <cas:attributes>
      <cas:firstname>John</cas:firstname>
      <cas:lastname>Doe</cas:lastname>
      <cas:email>jdoe@example.org</cas:email>
      <cas:affiliation>staff</cas:affiliation>
      <cas:affiliation>faculty</cas:affiliation>
    </cas:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>

The changes in this PR extract these attributes and pass them through the UserBadge, ensuring the authentication workflow receives all necessary data without requiring a dedicated object. Since we're simply transferring attributes for use by the application's user provider, this approach is sufficient.

I've committed the necessary changes to align with the CAS documentation. All tests now pass after adding some additional cases. However, I'm still encountering issues in PHP 8.2 (low-deps).