Skip to content

Conversation

@erseco
Copy link

@erseco erseco commented Mar 10, 2025

Q A
Branch? 7.3
Bug fix? no
New feature? yes
Deprecations? no
Issues
License MIT

Description

This pull request enhances the CAS authentication process by extracting user attributes from the CAS response and passing them to the UserBadge. This ensures that additional information, such as email or roles, can be accessed within authentication workflows.

Changes

Test Updates

Why?

  • Provides better integration with Symfony’s security system.
  • Ensures CAS user attributes (like email and roles) are available in authentication workflows.
  • Improves maintainability by aligning with how attributes are handled in OIDC authentication.

Tests updated and verified
No backward compatibility breaks

Let me know if any adjustments are needed! 🚀

@carsonbot
Copy link

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

@carsonbot

This comment was marked as resolved.

@welcoMattic
Copy link
Member

@nacorp friendly ping 😉

@nacorp
Copy link
Contributor

nacorp commented Mar 11, 2025

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

@chalasr
Copy link
Member

chalasr commented Mar 13, 2025

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.

@erseco
Copy link
Author

erseco commented Mar 18, 2025

@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>[email protected]</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).

@fabpot fabpot modified the milestones: 7.3, 7.4 May 26, 2025
@nxtpge
Copy link

nxtpge commented Nov 9, 2025

Hello @erseco and @nacorp.

As far as I know, the current implementation of the CAS protocol in Symfony follows the version 2.0 (Cas2Handler, Symfony Blog, Symfony Docs).

However, the presence of attributes in the /serviceValidate response document seems to be part of the version 3.0 only (CAS Protocol Specification).

Therefore, what do you think about using this pull request as an opportunity to add, beforehand, a version option to the cas configuration to handle these differences?

# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    cas:
                        validation_url: https://www.example.com/cas/validate
                        version: 2 # Or 3

@nxtpge
Copy link

nxtpge commented Nov 9, 2025

All things considered, if there is not so much differences between the versions 2.0 and 3.0 of the CAS protocol specification, then a renaming could be enough (e.g. CasTokenHandler).

@erseco
Copy link
Author

erseco commented Nov 9, 2025

Thanks @nxtpge, IMHO your suggestion makes sense and will be better to simply rename it to CasHandler as you mentioned. I’ve also updated the PR to the latest 7.4 version.

@carsonbot carsonbot changed the title Enhancing CAS authentication handling by extracting user attributes [Security] Enhancing CAS authentication handling by extracting user attributes Nov 10, 2025
@benjamin-feron
Copy link

benjamin-feron commented Nov 10, 2025

Hi,

Thanks for this great improvement!

In my previous discussion #57390, I mentioned that I had applied a patch similar to @eresco’s to fix the issue with retrieving additional attributes from the CAS response, and later implemented a workaround in CasAuthenticatorListener.php to remove the CAS ticket from the URL after a successful authentication.

Could you please confirm whether this workaround is still needed with the changes introduced in this PR, or if the new behavior already handles this case?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants