Disallow eppn/affiliation to be asserted by the wrong IdP

[William Spooner]

On 11 Oct 2012, at 23:25, Cantor, Scott wrote:

> On 10/11/12 6:05 PM, "William Spooner" <william.spooner at eaglegenomics.com>
> wrote:
>> 
>> 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.
> 
> You can, you just shouldn't. Scope is a semantic concept that doesn't
> apply to attributes just because they have a domain on the end. The reason
> is the opposite of your problem: imposing scoped processing by accident on
> something that isn't really meant to be filtered on that basis. Email
> address is definitely such a case.
> -- Scott
> 

Tricky. I'm trying to solve the problem that eppn's were (I presume) devised to solve; namely that persistent NameIDs do not fit my applications. Except that I'm talking to IdPs that don't implement eppn's (or scope extensions, for that matter). So in the context of enterprise (mainly AD-backed) IdPs it's like beating a round peg through a square hole, and IdP-specific semantics rule. It transpires that the path of least resistance is to abstract the IdP-specific logic into custom apache handlers. That's not to denigrate shib - it seems to be providing exactly the raw materials I need to do the mucky stuff behind the scenes.

Best,

Will