Provide SAML metadata facility for CAS
Description
Environment
depends on
has dependent
is related to
Activity
Marvin Addison June 28, 2018 at 7:01 PM
Code changes per above have been committed and profile specification updated accordingly. See https://wiki.shibboleth.net/confluence/display/SC/CASMetadataProfile.
Marvin Addison June 28, 2018 at 2:27 PM
Per discussion on IDP-644, plan to rework a couple points:
Use spec-defined URN for SLO location, urn:mace:shibboleth:profile:CAS:logout, to indicate that the logout message is delivered to the same URI that requested a ticket.
Use SPSSODescriptor with ACS endpoint to indicate proxy support.
Marvin Addison June 21, 2018 at 6:21 PM
Proposed metadata profile that is consistent with latest code:
https://wiki.shibboleth.net/confluence/display/IDP30/CASMetadataProfile
Marvin Addison June 20, 2018 at 4:47 PM
Added a further commit, b90991490881714028d9b1a5b81fee976712df35, to avoid repurposing SAML binding URI for CAS endpoints per suggestion from . Use the following binding URIs:
https://www.apereo.org/cas/protocol/login for ACS endpoint
https://www.apereo.org/cas/protocol/logout for SLO endpoint
Marvin Addison June 20, 2018 at 10:56 AM
I have completed the implementation for this feature in the following commits:
cbfbd4c24e26d55d3de73f76a5d3916292096062
2bc5501ca5f42d234044943182fade8d73dba00d
A sample metadata file with CAS entities:
It remains to configure metadata indexes needed to support the feature; I'm unsure exactly how to do that mostly because I don't understand the performance/resource impact from the additional indexing. Ideally we would index only CAS entities and endpoints to minimize the size of the index, but I don't know to do that. Assuming that's possible I would think it would be safe to enable as part of the default configuration. Suggestions welcome and appreciated.
Provide a SAML metadata facility for use by the CAS protocol to drive relying party selection. The new facility should be a complement to the existing ServiceRegistry facility and should be targeted at defining single logical relying parties (in contrast to ServiceRegistry). The use cases that were mentioned during discussion of this feature:
Per-RP UI customization
CAS proxy trust credential configuration
Link to mailing list discussion: http://marc.info/?l=shibboleth-dev&m=142859713909271&w=2