Shibboleth Developers

["Tom Scavo" <>]

On 10/25/07, Scott Cantor 
<>
 wrote:
>
> Basically, saying that the presence of a value triggers a denial of access
> is very dependent on attribute release never falling into the user's hands.
> If I can gain access simply by refusing the release of some of my
> attributes, obviously I will.

This is an interesting and relevant question, I think.  I don't really
have a specific suggestion one way or the other, but I'll offer our
own experience along these lines FWIW.

This is akin to so-called blacklisting.  We've implemented a blacklist
PDP in GridShib for GT and have an expanded implementation on our
roadmap.  At the moment, we allow blacklisting based on the IP address
and DNS address in the authn statement.  (Yes, we know these aren't
reliable data, but for runaway processes and the like, it's a useful
starting point.)  Ranges of IP addresses will also be supported.

Blacklisting based on persistent name identifiers is an often
requested feature.  We already have an equivalence relation defined on
SAML name identifiers, so this will be relatively easy to implement.
The hard part is making this usable for administrators.

Related to this are blacklists of persistent identity attributes such
as ePPN, ePTID, and so forth.  If name identifiers present a usability
problem, however, combined lists of name identifiers and identity
attributes are even more frightening.  This may require a database, I
don't know.

As you've noted, blacklisting based on non-identity attributes is not
so useful.  At one point, we thought that any attribute might be
blacklisted, and while it doesn't hurt to add a group membership
(e.g.) to a blacklist, it may not always have the desired effect.  On
the other hand, there's no difference between identity and
non-identity attributes as far as the actual mechanism is concerned,
so the latter will automatically be supported.

Tom