CAS protocol attribute release

[Walter Forbes Hoehn (wassa)]

Good point. That used to be broken, but it appears to have been fixed in 3.2:

https://issues.shibboleth.net/jira/browse/IDP-762

So, I guess either works now. Some CAS client configurations will, of course, work with the below as well, particularly when there is a local app session that is bootstrapped from CAS at a single endpoint:

 <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp.example.org" />

-WFH


> On Feb 22, 2016, at 5:55 PM, Kevin Foote <kpfoote at uoregon.edu> wrote:
> 
> 
> 
>> On Feb 22, 2016, at 3:41 PM, Walter Forbes Hoehn (wassa) <wassa at memphis.edu> wrote:
>> 
>> You use the standard attribute filter (attribute-filter.xml). The only tricky bit is that the “attribute requester” can vary depending on the configuration of the CAS client. In that case, you’ll need to do something like this:
>> 
>> <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterRegex" regex="^https://foo.test.edu/.*$" />
> 
> Doesn’t it obey this as well?  I don’t have any CAS clients that need / use attributes (yet or hopefully ever).. 
> So this is just me thinking.. not tested :) 
> 
> <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="uolocal-cas-services" />
> 
> Assuming a local CAS ServiceDefinition bean with the following.  
> p:group=“uolocal-cas-services"
> 
> --------
> thanks
> kevin.foote
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net