the intercept page only shows the released attributes based on attribute-filter.xml (which may lack the attribute which corresponds to the username). So it would be fine to have the cas:user displayed there for CAS logins by default.
Environment
None
Activity
Scott Cantor
May 8, 2023 at 12:06 PM
Closing for the reasons I mentioned, it's just not practical to do this.
Scott Cantor
July 26, 2021 at 1:27 PM
Architecturally, the consent flow is not designed for this purpose in part because of timing. The same issue applies with SAML or OpenID where the NameID or sub claim isn't technically computed until later in the process. They're also not meant to be "blocked" by the user, so that breaks the semantics of the "per-attribute" mode.
CAS may (or may not) be different, but I think the best thing is to include an attribute that contains the same value as a means of signaling the data that will be sent, and preclude use of the per-attribute feature since it would be deceptive.
The CAS login flow by default only seems to provide the username (principalName?) which the user used to login.
However, if combined with the attribute-release intercept in
relying-party.xml:{{ <bean parent="CAS.LoginConfiguration" }}
p:postAuthenticationFlows="#{ {'attribute-release'} }" />the intercept page only shows the released attributes based on
attribute-filter.xml(which may lack the attribute which corresponds to the username). So it would be fine to have thecas:userdisplayed there for CAS logins by default.