Shibboleth IDP 3 as CAS Server

[Walter Forbes Hoehn (wassa)]

The CAS protocol support components do, in fact, use the standard attribute filter.  The only catch is that there is no canonical entity ID, so the policy has to reference the URL of the service.  Depending on the CAS client, this might not be fixed per service.  The workaround is to do something like the following:  

<afp:AttributeFilterPolicy id="wfhCasExample">
    <afp:PolicyRequirementRule xsi:type=“basic:AttributeRequesterRegex" regex="^https://example.example.edu/.*$" />
    <afp:AttributeRule attributeID="mail">
      <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
</afp:AttributeFilterPolicy>

-Walter


> On Jun 11, 2015, at 2:39 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 6/11/15, 7:36 PM, "Jesse Martinich" <martinicj at sou.edu> wrote:
> 
>> I took from the CAS protocol configuration documentation 
>> (https://wiki.shibboleth.net/confluence/display/IDP30/CasProtocolConfigura
>> tion) that there were
>> was nothing in the way of relying party config beyond the 
>> defaultRelyingParty bean. It seems that the serviceRegistry takes the 
>> place of metadata configuration for CAS services. I assume there is 
>> something analogous to the attribute-filter for registered CAS
>> services?
> 
> I'm guessing yes, but Marvin would have to help with that. He's also 
> working on making it possible to use SAML metadata for that and then I 
> think the filter layer would be the same in both, but that's all true now. 
> I would assume some kind of filter rule is needed (there's only one filter 
> component, nothing specific to CAS), but I don't know what it would look 
> like.