This thread in gridshib-dev is relevant:

http://www.globus.org/mail_archive/gridshib-dev/2008/02/msg00040.html

Recall that blacklisting in GS4GT is enabled by setting the
"enableBlacklisting" config parameter, while a file of blacklisted IP addresses
is specified by setting the "blacklistIPAddressesFile" config parameter. 
Analogously, we have added a new config parameter
"blacklistNameIdentifiersFile" that specifies a file of blacklisted name IDs. 
So a typical container-level config might look like the following:

<deployment name="defaultServerConfig" ...>
    <globalConfiguration>
        ...
        <parameter name="containerSecDesc"
            value="etc/globus_wsrf_core/global_security_descriptor.xml"/>

        <!-- add the following GridShib config params -->

        <parameter name="global-metadataPath"
            value="/etc/grid-security/metadata"/>

        <parameter name="global-enableBlacklisting" value="true"/>

        <parameter name="global-blacklistIPAddressesFile"
            value="/etc/grid-security/blacklists/blacklist-ip-addresses.txt"/>

        <parameter name="global-blacklistNameIdentifiersFile"
            value="/etc/grid-security/blacklists/blacklist-name-ids.txt"/>

        <parameter name="global-consultDefaultGridmap" value="false"/>

        <parameter name="global-gridshibAuthzPolicyFile"
            value="/etc/grid-security/policy/core-authz-policy.xml"/>
        ...
    </globalConfiguration>
    ...
</deployment>

Added the new "blacklistNameIdentifiersFile" config parameter to the
(mis-named) ShibbolethConstants interface:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/gt/interceptors/java/source/src/org/globus/gridshib/gt/authorization/ShibbolethConstants.java?revision=1.2.2.17&view=markup&pathrev=gridshib_gt_0_6_0_branch

Added a "blacklistNameIdentifiersFile" config parameter to the 4.0 EchoService:

http://viewcvs.globus.org/viewcvs.cgi/*checkout*/gridshib/gt/echoservice/java/source-gt4.0/templates/wsdd-tmpl.xml?revision=1.1.2.2&pathrev=gridshib_gt_0_6_0_branch

The logic for handling the new blacklist of name identifiers is pretty much
what you'd expect.  If blacklisting is enabled (i.e., enableBlacklisting is set
to true in the config file), the initialize method of SAMLBlacklistPDPImpl
looks for blacklistIPAddressesFile and/or blacklistNameIdentifiersFile.  At
least one blacklist must be defined, otherwise an exception is thrown.

To make an access control decision, SAMLBlacklistPDPImpl searches both
blacklists in turn (assuming both are defined).  The PDP returns DENY if and
only if at least one of the blacklists contains a blacklisted item; otherwise
it returns INDETERMINATE.  Note that both blacklists are searched, even if the
first blacklist contains a blacklisted item.  We do this so all blacklisted
items get logged.

Successfully tested blacklist of name identifiers.  Committed all files to
gridshib_gt_0_6_0_branch.

I think this is all right on. One question - if the NameIdentifier format is
something other than the three you list, the Name is ignored as far as
blacklisting is concerned?

(In reply to comment #7)
> if the NameIdentifier format is
> something other than the three you list, the Name is ignored as far as
> blacklisting is concerned?

Are you asking what kind of name identifiers may be added to the list, or are
you asking how the PDP searches for a matching name identifier?  I'll try to
answer both questions.

Any NameIdentifier that has a globally unique string value may be added to the
list.  I can't give an exhaustive list of NameIdentifier formats that satisfy
this criterion since the possibilities are endless.

The algorithm compares the value of the NameIdentifier with each value on the
list by doing an exact string comparison.  It does not check the Format or the
NameQualifier attributes.  (How can it? The list is a simple list of strings.)

Oops, you've already found a bug :-)

<NameIdentifier
  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
  NameQualifier="some_qualifier_that_makes_the_name_unique">
  trscavo
</NameIdentifier>

<NameIdentifier
  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
  NameQualifier="some_other_qualifier_that_makes_the_name_unique">
  trscavo
</NameIdentifier>

These are not the same identifier (and now you see why this is a hard problem
:)

I need to modify the algorithm so that a NameIdentifier with a NameQualifier
attribute never causes the PDP to return DENY.  Agreed?

> Are you asking what kind of name identifiers may be added to the list, or are
> you asking how the PDP searches for a matching name identifier?  I'll try to
> answer both questions.

Neither. I'm asking what happens if GS4GT encounters a Format that is not in
the list of three you provided in the description?

> I need to modify the algorithm so that a NameIdentifier with a NameQualifier
> attribute never causes the PDP to return DENY.  Agreed?

I agree that is reasonable.

I think that may also be the answer to my question above. If GS4GT encounters a
Format not in the list of 3, it mimics that behavior(?)

Von

(In reply to comment #9)
> I'm asking what happens if GS4GT encounters a Format that is not in
> the list of three you provided in the description?

As I said, GS4GT doesn't consider the Format or NameQualifier while consuming
the NameIdentifier.  Attribute Acceptance Policy determines whether or not a
NameIdentifier is accepted.  Currently, all are accepted.  (See Bug 5882 for
related policy requirements.)

> > I need to modify the algorithm so that a NameIdentifier with a NameQualifier
> > attribute never causes the PDP to return DENY.  Agreed?
> 
> I agree that is reasonable.
> 
> I think that may also be the answer to my question above. If GS4GT encounters a
> Format not in the list of 3, it mimics that behavior(?)

No, unless we want to hardcode exceptions into AttributeAcceptancePIP, I think
it's better to simply accept all NameIdentifiers.

While updating the Quick Start with respect to blacklisting, it became clear
that the issue alluded to in Comment #8 needs a simple solution so that
deployers know precisely what can and can't be included in a blacklist of name
identifiers.  Here's an approach that I think will work:

- In SAMLSecurityContext, when consuming a SAML Subject element, determine if
the NameIdentifier is "blacklistable," and if so, add a new Principal item to
the security context.

- Systematically log the Principal items in SecurityContextLogger.

- Modify the logic in SAMLBlacklistPDPImpl to iterate over the Principal items,
not the SAMLIdentity items.

- A nice consequence of the above is that the Subject DN of the authenticated
user (as provided by GT) is blacklistable.

So now the documentation reads: "Any Principal item appearing in the log file
can be added to a blacklist of name identifiers."

Currently, mapped usernames are added to the security context as Principal
items.   The strategy outlined in Comment #11 requires that this be changed. 
(It's arguably a bug anyway.)  Instead, mapped usernames will be carried along
with the attributes that map to them.

The TODO items in Comment #11 are done.  The code has been committed to
gridshib_gt_0_6_0_branch.

(In reply to comment #12)
> Currently, mapped usernames are added to the security context as Principal
> items.   The strategy outlined in Comment #11 requires that this be changed. 

On second thought, I think I'll leave this as it is.  In fact, the GS4GT
security context now contains three types of java.security.Principal objects:

org.globus.gsi.jaas.GlobusPrincipal
org.globus.gsi.jaas.UserNamePrincipal
org.globus.gridshib.gt.security.SAMLPrincipal

By definition, a SAMLPrincipal corresponds to an unqualified SAML name
identifier string value.  (The SAMLPrincipal class will be moved to GridShib
Common at a later date.)

Any SAMLPrincipal is blacklistable.  The GlobusPrincipal is also blacklistable.
 UserNamePrincipal, which represents a mapped username, is not blacklistable.

For the record, here's a list of changes I made to implement this new blacklist
capability in GS4GT:

SAMLPrincipal:
- extends org.globus.gsi.jaas.SimplePrincipal
- (move this class to GS-ST)

AttributeAcceptancePIPImpl:
- if a SAMLIdentity is trusted, create a SAMLPrincipal
- (push this functionality back into GS-ST)

GS4GTSecurityContext:
- implement getGlobusPrincipal() method
- implement getSAMLPrincipals() method
- (push getSAMLPrincipals() method into GS-ST)
- remove unused getUsernames() method
- implement getUserNamePrincipals() method
- remove redundant toString() method
- refactor toString(boolean) method
- (move most of toString(boolean) to SAMLSecurityContext)

SAMLBlacklistPDPImpl:
- check IP address
- check all SAMLPrincipals
- check GlobusPrincipal

GS4GTSecurityContextLogger:
- log GlobusPrincipal
- log SAMLPrincipals
- (push logging of SAMLPrincipals into GS-ST)
- log UserNamePrincipals
- implement (redundant) quote(String) method
- (make SecurityContextLogger.quote(String) public)

The notes in parentheses are things that need to be done in the next version of
GS-ST.  When that's finished, a new gridshib-common*.jar needs to be integrated
into GS4GT.

This blacklist implementation will be released with GS4GTv0.6.0.