EDIT: YOU PROBABLY DON'T NEED THIS. You can probably just use included StringEqualsTester. Cf. uPortal-user@ thread re.
A new HttpHeaderTester PAGS "tester". In PAGS config, allows writing configuration like this:
<test>
<attribute-name>ismemberof</attribute-name>
<tester-class>edu.wisc.my.groups.pags.testers.HttpHeaderTester</tester-class>
<test-value>uw:domain:my.wisc.edu:my_uw_developers</test-value>
</test>as a successor to currently available options.
(MyUW's uPortal is evolved from uPortal 4.2.1 and so uses PAGSGroupStoreConfig.xml.)
Entirely backwards-compatible in that one opts into using the new HttpHeaderTester by starting to declare it in place of the other testers in PAGS configuration. Don't declare this tester, and it won't be used for anything.
Covered by a new unit test which comprehensively demonstrates the features, behaviors of the new tester.
JavaDoc'ed. I didn't XML-escape the XML in the JavaDoc, but it's entirely readable in the source, and anyway someone else can come along and properly escape that if generating formal JavaDoc becomes an issue.
Current options include the RegexTester
<test>
<attribute-name>ismemberof</attribute-name>
<tester-class>org.jasig.portal.groups.pags.testers.RegexTester</tester-class>
<test-value>\S*uw:domain\:my\.wisc\.edu\:my_uw_developers\S*</test-value>
</test>Writing regular expressions is powerful but difficult. This regular expression will match a group like my_uw_developers_hrs. That's probably not the intent, but that is what that regex will do, and we've already tripped over this in production. It's possible to write tighter matching regular expressions, but that requires skill in writing regular expressions, and is just too much cognitive load to ask of the configurer for the trivial task of mapping in a Manifest (UW-Madison localized grouper; it releases group memberships via a multi-valued ismemberof shib heeader) group.
or the StringContainsTester
<test>
<attribute-name>ismemberof</attribute-name>
<tester-class>org.jasig.portal.groups.pags.testers.StringContainsTester</tester-class>
<test-value>uw:domain:my.wisc.edu:my_uw_developers</test-value>
</test>which makes it easier and cleaner to write a rule that is incorrect in that same not-sufficiently-tightly-matching way.
HttpHeaderTester is easy to configure (well, for a PAGS tester anyway) and automatically gets right this tight matching characteristic, such that
<test>
<attribute-name>ismemberof</attribute-name>
<tester-class>edu.wisc.my.groups.pags.testers.HttpHeaderTester</tester-class>
<test-value>uw:domain:my.wisc.edu:my_uw_developers</test-value>
</test>will match its intended Manifest group uw:domain:my.wisc.edu:my_uw_developers but will not match uw:domain:my.wisc.edu:my_uw_developers_sis.
That is, HttpHeaderTester makes it easy to implement the matching rule that the configurer almost certainly intends when matching against HTTP headers.
In some alternate universe, technology upstream of this tester would parse the HTTP headers into IPerson attributes, and would translate multi-value HTTP headers to multi-valued IPerson attributes. That's arguably the right thing for that architectural layer to do -- it's an abstraction violation for the PAGS tester tier to be relying upon implementation details of how HTTP headers are encoded or even that an attribute came from an HTTP header at all. By the time it gets to PAGS it should be in the abstraction of person attributes, not of HTTP headers with their semicolon delimiters.
If that enhancement did come along, this tester would work fine unchanged. It supports multiple String values for the IPerson attribute through its superclass StringTester supporting this. HttpHeaderTester splits attribute values on semicolons, and is perfectly happy having no semicolon to split on, as demonstrated by unit test.
Apache2.