Disallow eppn/affiliation to be asserted by the wrong IdP

[William Spooner]

On 11 Oct 2012, at 18:28, Peter Schober wrote:

> * William Spooner <william.spooner at eaglegenomics.com> [2012-10-11 18:06]:
>> The upshot; it's going to be too much effort to configure shibboleth
>> to handle this natively at the SP end. My solution is an apache
>> PerlAuthzHandler that uses the persistent-id to check that the
>> userid is from the correct IdP entity based on per-IdP
>> regexps. Using a handler means that the application layer remains
>> unaware of IdP shenanigans. Bit of a shame, but it's a case of
>> "better the devil you know".
> 
> No idea what these "userid"s are (probably email adresses?) but we can
> assume they're not scoped attributes on the wire (but simple string
> values), so you can't check scopes on them, yes.
> While you could probably create AttributeValueRegex type rules in your
> attrobute-policy.xml to make sure arbitrary string values can only
> come from some IdPs but not others I would agree that this is not
> making your life or deployment easier.
> -peter

Hi Peter,

I map "userid" to the most likely looking attribute; currently the default (urn:kid:0.9.2342.19200300.100.1.1) and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn. I also copy "eppn" to "userid" in the apache handler when available (I've yet to work out how to map one Attribute "name" to multiple "ids" in the AttributeExtractor). 

I can't see any difference between scoped and non-scoped Attributes in the Assertion from the IdP, which leads me to assume that I can arbitrarily 'scope' any attribute by specifying an AttributeDecoder. The key problem as I see it is defining scope to a MetadataProvider where it is omitted by the provider themselves. 

Per-IdP AttributeValueRegex sounds interesting, but I can't find any documentation for the SP side of things. In the mean time my Apache handler is providing equivalent functionality.

Thanks again for your help - this has been an illuminating exercise!

Will