Rationalize relying party ID usage with CAS + metadata
Fixed
Description fields
Basics
Logistics
Basics
Logistics
Description
I think I've raised the issue of the attribute "recipient" value being the CAS service URL instead of the metadata-derived entityID before and we had discussed getting this adjusted in 4.0 to avoid inadvertent breakage.
I still would really prefer that we make things consistent with SAML and OIDC and make sure that if metadata is used that the entityID is used as the relying party "name".
My suggestion for CAS would be:
Adjust BuildSAMLMetadataContextAction so that the RelyingPartyContext's ID is reset in the event that actual metadata is being stored off
Make sure that any actual CAS service URL usage in the flows are derived from the CAS Service object and not the RelyingPartyContext ID
I think documenting the change is sufficient because metadata usage is still not that common with CAS anyway. Plus a lot of regex-based requester filtering being done will often match the entityID that gets used anyway.
I think I've raised the issue of the attribute "recipient" value being the CAS service URL instead of the metadata-derived entityID before and we had discussed getting this adjusted in 4.0 to avoid inadvertent breakage.
I still would really prefer that we make things consistent with SAML and OIDC and make sure that if metadata is used that the entityID is used as the relying party "name".
My suggestion for CAS would be:
Adjust BuildSAMLMetadataContextAction so that the RelyingPartyContext's ID is reset in the event that actual metadata is being stored off
Make sure that any actual CAS service URL usage in the flows are derived from the CAS Service object and not the RelyingPartyContext ID
I think documenting the change is sufficient because metadata usage is still not that common with CAS anyway. Plus a lot of regex-based requester filtering being done will often match the entityID that gets used anyway.