<div dir="ltr">Mahalo for the feedback. We'll look into the SAML metadata route. We do have a number of CAS registrations that make extensive use of the registry's regex feature, so those will probably take some care to disentangle and replace with metadata equivalents.<div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jul 11, 2025 at 5:59 AM Paul Engle via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I second the suggestion to use the SAML style metadata for registered CAS services. We only use the legacy registry for our default catch-all definitions. Anything that actually needs specific configuration or attribute release gets added via metadata.</div><div><br></div><div>Further to that, there is a property setting idp.cas.relyingPartyIdFromMetadata, which I think defaults to false (or at least it did at the time I added it to our config). If you set that to true, then you can use the entityID you put into the metadata for any activation conditions you might want to use. Otherwise, you have to use serviceURLs, which in our case gets cumbersome. We frequently have many serviceURLs for the same registered cas service due to clustering & the general lack of understanding on our application owners' parts.</div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>-- </div><div>Paul Engle</div><div>IAM Architect</div><div>Identity & Access Management</div><div><a href="mailto:pengle@rice.edu" target="_blank">pengle@rice.edu</a> 713-348-4702</div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 9, 2025 at 8:16 PM Paul B. Henson via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Jul 09, 2025 at 02:58:25PM -1000, Baron Fujimoto via users wrote:<br>
> Shibboleth (CAS is currently being handled via Apereo CAS). With<br>
> Shibboleth, how do you specify the set of attributes released by<br>
> /serviceValidate or /samlValidate? I didn't find this obvious anywhere<br>
> under the CasProtocolConfiguration wiki hierarchy.<br>
<br>
If you use the xml interface for defining CAS metadata, eg:<br>
<br>
<EntityDescriptor entityID="<a href="https://icinga.unx.cpp.edu/" rel="noreferrer" target="_blank">https://icinga.unx.cpp.edu/</a>"><br>
<SPSSODescriptor<br>
protocolSupportEnumeration="<a href="https://www.apereo.org/cas/protocol" rel="noreferrer" target="_blank">https://www.apereo.org/cas/protocol</a>"><br>
<AssertionConsumerService<br>
Binding="<a href="https://www.apereo.org/cas/protocol/login" rel="noreferrer" target="_blank">https://www.apereo.org/cas/protocol/login</a>"<br>
Location="<a href="https://icinga.unx.cpp.edu/" rel="noreferrer" target="_blank">https://icinga.unx.cpp.edu/</a>"<br>
index="1"/><br>
</SPSSODescriptor><br>
</EntityDescriptor><br>
<br>
You release them the same way you do SAML ones, either explicitly for<br>
that entity id:<br>
<br>
<AttributeFilterPolicy id="example"><br>
<PolicyRequirementRule xsi:type="Requester"<br>
value="<a href="https://icinga.unx.cpp.edu/" rel="noreferrer" target="_blank">https://icinga.unx.cpp.edu/</a>" /><br>
<br>
or by tagging the metadata:<br>
<br>
<MetadataFilter xsi:type="EntityAttributes"><br>
<saml:Attribute<br>
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"<br>
Name="<a href="http://shibboleth.net/ns/attributes/releaseAllValues" rel="noreferrer" target="_blank">http://shibboleth.net/ns/attributes/releaseAllValues</a>"<br>
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><br>
<saml:AttributeValue>memberOf</saml:AttributeValue><br>
</saml:Attribute><br>
<Entity><a href="https://icinga.unx.cpp.edu/" rel="noreferrer" target="_blank">https://icinga.unx.cpp.edu/</a></Entity><br>
</MetadataFilter><br>
<br>
and releasing by tag:<br>
<br>
<AttributeFilterPolicy id="memberof_by_tag"><br>
<PolicyRequirementRule xsi:type="EntityAttributeExactMatch"<br>
attributeName="<a href="http://shibboleth.net/ns/attributes/releaseAllValues" rel="noreferrer" target="_blank">http://shibboleth.net/ns/attributes/releaseAllValues</a>"<br>
attributeValue="memberOf" /><br>
<AttributeRule permitAny="true" attributeID="memberOf" /><br>
</AttributeFilterPolicy><br>
<br>
or any other documented mechanism.<br>
<br>
If you're just starting with CAS in the idp, I'd advise using the SAML<br>
compatible metatdata rather than the legacy CASServiceRegistry. That<br>
allows you to just treat CAS services basically the same as SAML ones,<br>
as least for attribute release purposes.<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="arial, sans-serif">Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> ::: UH Information Technology Services<br>minutas cantorum, minutas balorum, minutas carboratum descendus pantorum</font></div></div>