Shibboleth Developers

[Scott Cantor <>]

> There is NO wildcarding in shar (the way it is implemented).  
> Shar either matches exacly or "default" shar is used.  That is it.
> 
> What I meant to say was we never established how shar is 
> releated to the hostname of the resource.  Would there be a config
file to 
> map them? etc.

There's no requirement to do so, which is one reason why the spec rules
out the wildcard+wildcard case, since it's not clear how to define the
meaning of that kind of many->many situation in all cases.

> I chenged the admin ARP to the following so there would be no 
> confusion.
> 
> ARP: admin(admin)
>         SHAR: no.other.match(default)
>                 URL: *.internet2.edu [edu, internet2, *]
>                         eduPersonAffiliation
>                         eduPersonPrincipalName
>                 URL: *.edu [edu, *]
>                         eduPersonAffiliation

The problem here is that what this means is that you *are* wildcarding
the SHAR. You can't say "any SHAR, wildcarded URL" without violating
what the document currently says. And the reason the document says this
is that if you think about the fact that any given resource is
associated with one SHAR, it doesn't make any sense to say "any SHAR,
these resources". "Those resources" have a SHAR (or two, or more), and
that's the one whose policy is being created.

On the other hand, it's fine to say "for any resources handled by these
SHARs, do this", which is what you're trying to express.

What ends up happening is that you have a special case for the default
ARP in which you're implicitly creating a bunch of ARPs that apply to a
bunch of SHARs whose name matches the hostname of its resources.

The above means:

         SHAR: *.internet2.edu [edu, internet2, *]
                  URL: * (implicitly http(s?)://*.internet2.edu/*)
                         eduPersonAffiliation
                         eduPersonPrincipalName
         SHAR: *.edu [edu, *]
                  URL: * (implicitly http(s?)://*.edu/*)
                         eduPersonAffiliation

The problem is that if you get a SHAR request that matches the default
case, you don't turn around and look at the URL. You have to assume the
SHAR is sending you a resource that matches.

Otherwise, all I have to do as a rogue (but still trusted) requester is
send you a message with the right URL in it (say something with
internet2.edu) and you'll give me more information than I should get
based on the policy. You can argue that the club makes that a no-no, but
why rely on that when the architecture specifically provides for
preventing this?

This "attack" doesn't work if you don't do the additional URL
examination in the default case, because my authenticated identity won't
match *.internet2.edu, and so I won't get EPPN, no matter what I send
for Resource.

Does that explain it any better?

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--