CAS Protocol Service Registry (Shib 3.3)

[Dan Malone]

On 1/3/18 9:44 AM, Andrew Morgan wrote:
> On Tue, 2 Jan 2018, Dan Malone wrote:
>
>> We are looking for a way to simplify the configuration of our CAS services.
>> In our current CAS usage, we are not doing any additional attribute release, only username.
>>
>> From what we can tell, to enable a CAS client, at a minimum we need to do two things:
>>
>> 1. add the service URL in the cas.serviceRegistry bean in cas-protocol.xml
>> 2. release the username attribute in attribute-filter.xml
>>
>> To make it easier to add new services, we would like to be able to add the service in once place.
>>
>> For option A, we add a very permissive wildcard to cas-protocol.xml and control services using attribute-filter.xml. We got this to work, but when you have an unauthorized service, a ticket is granted and the failure is not noticed until the verification step. Neither the user or the service knows why because the ticket was issued.
>>
>> For option B, we would like to use cas-protocol.xml to limit the services and in attribute-filter.xml, release username to all CAS services. This provides the user friendly message "...application you have accessed is not registered..." similar to pre-shib CAS. However, we can not use the very permissive wildcard in attribute-filter.xml, because this would also release via SAML to all entities in, for example, the InCommon metadata, and our campus is not ready to release to R&S, much less the whole aggregate. (Yes, we're working on the R&S release)
>>
>> So, here's my question:
>>
>> How do we release an attribute to all services defined in the cas.serviceRegistry bean list?
>
> Define your services in cas-protocol.xml with a p:group="foo" property, like this:
>
>   <bean class="net.shibboleth.idp.cas.service.ServiceDefinition"
>         c:regex="https://your-service\.example\.edu"
>         p:group="standard-attributes"
>         p:authorizedToProxy="false"
>         p:singleLogoutParticipant="false" />
>
> Then configure attribute release for that group in attribute-filter.xml:
>
>   <AttributeFilterPolicy id="cas-standard-attributes">
>       <PolicyRequirementRule xsi:type="OR">
>           <Rule xsi:type="InEntityGroup" groupID="standard-attributes" />
>       </PolicyRequirementRule>
>       <AttributeRule attributeID="uid">
>           <PermitValueRule xsi:type="ANY"/>
>       </AttributeRule>
>   </AttributeFilterPolicy>
>
>
> When you add a new service to cas-protocol.xml, make sure you include the p:group property.
>
>     Andy
> -- 
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
This is great and is working with the small tests I've done today.
Thanks!

I found this: https://wiki.shibboleth.net/confluence/display/IDP30/CasProtocolConfiguration

    The fields of ServiceDefinition are straightforward:
    ...
        2. group - human-readable name of the group of services
    ...


It did not occur to me that this group was equivalent to an EntityGroup.
Is this documented somewhere else or should this be obvious if I understood the beans better?

Thanks,
Dan
-- 
Dan Malone
Lead Identity Management Architect
Information Technology Services
California Polytechnic State University
San Luis Obispo, California

Direct 805-756-6326
dmalone at calpoly.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180103/6cd34c38/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4207 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20180103/6cd34c38/attachment.p7s>