Disallow eppn/affiliation to be asserted by the wrong IdP

[William Spooner]

On 11 Oct 2012, at 15:26, Peter Schober wrote:

> * William Spooner <william.spooner at eaglegenomics.com> [2012-10-11 14:15]:
>> Two of the IdPs I'm dealing with do not define scope in their
>> metadata. I'm working with local XML documents, so could add
>> manually, but take Peter's point that this adds potential for
>> (potentially insecure) issues on any metadata update.
> 
> If you're willing to do the work you can still to it (check for valid
> metadata, check for valid signatures on the metadata, check the
> validUntil date, etc.) and merge with your local changes.
> Or simply let some script notify you when the entity you're interested
> in changed remotely so that you can pull in those changes to your
> local copy.
> But that's creating extra work for you, for not yet clear benefits.
> 
>> I admit I'm trying to bend non-edu IdPs to fit the securely scoped
>> shib eppn/affiliation model. It looks like it _could_ be done, but
>> increasingly feels like a hack. Which is a pity as eppns make much
>> more forgiving REMOTE_USER IDs than persistent_ids. Oh well - back
>> to relying on persistent_id and custom application code. 
> 
> edu or non-edu isn't the issue (and the "e" in ePPN is for "edu", of
> course, so you already know that ;)
> Everyone can use the existing metadata extensions to specify
> "registered" scopes. You can also define your own attributes making
> use of scopes and then check for those.
> But one of the requirement for scope checking is that the attribute is
> scoped in protocol messages, i.e., that the type of the attribute is
> a scoped one. Which, somewhat counter-inuitively, is not the case for
> the RFC mail attribute (if that is of interest; you were not clear at
> all what attributes scoped you'd need to check).
> -peter

Thanks Peter,

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".

Best,

Will