<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" data-smartmail="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 gmail_quote_container"><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">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>