Attributes for CAS?

[Paul Engle]

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.

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.

-- 
Paul Engle
IAM Architect
Identity & Access Management
pengle at rice.edu 713-348-4702


On Wed, Jul 9, 2025 at 8:16 PM Paul B. Henson via users <
users at shibboleth.net> wrote:

> On Wed, Jul 09, 2025 at 02:58:25PM -1000, Baron Fujimoto via users wrote:
> > Shibboleth (CAS is currently being handled via Apereo CAS). With
> > Shibboleth, how do you specify the set of attributes released by
> > /serviceValidate or /samlValidate? I didn't find this obvious anywhere
> > under the CasProtocolConfiguration wiki hierarchy.
>
> If you use the xml interface for defining CAS metadata, eg:
>
>   <EntityDescriptor entityID="https://icinga.unx.cpp.edu/">
>     <SPSSODescriptor
> protocolSupportEnumeration="https://www.apereo.org/cas/protocol">
>       <AssertionConsumerService
> Binding="https://www.apereo.org/cas/protocol/login"
>                                 Location="https://icinga.unx.cpp.edu/"
>                                 index="1"/>
>     </SPSSODescriptor>
>   </EntityDescriptor>
>
> You release them the same way you do SAML ones, either explicitly for
> that entity id:
>
> <AttributeFilterPolicy id="example">
>     <PolicyRequirementRule xsi:type="Requester"
>        value="https://icinga.unx.cpp.edu/" />
>
> or by tagging the metadata:
>
>         <MetadataFilter xsi:type="EntityAttributes">
>           <saml:Attribute
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>                           Name="
> http://shibboleth.net/ns/attributes/releaseAllValues"
>
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
>             <saml:AttributeValue>memberOf</saml:AttributeValue>
>           </saml:Attribute>
>           <Entity>https://icinga.unx.cpp.edu/</Entity>
>         </MetadataFilter>
>
> and releasing by tag:
>
>   <AttributeFilterPolicy id="memberof_by_tag">
>     <PolicyRequirementRule xsi:type="EntityAttributeExactMatch"
>                            attributeName="
> http://shibboleth.net/ns/attributes/releaseAllValues"
>                            attributeValue="memberOf" />
>     <AttributeRule permitAny="true" attributeID="memberOf" />
>   </AttributeFilterPolicy>
>
> or any other documented mechanism.
>
> If you're just starting with CAS in the idp, I'd advise using the SAML
> compatible metatdata rather than the legacy CASServiceRegistry. That
> allows you to just treat CAS services basically the same as SAML ones,
> as least for attribute release purposes.
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250711/f11ca0b1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5139 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20250711/f11ca0b1/attachment.p7s>