Bugzilla – Bug 5960
implement a blacklist of name IDs
Last modified: 2008-04-25 21:12:37
You need to
before you can comment on or make changes to this bug.
GS4GT v0.6.0 Alpha has the capability to blacklist an IP address. Similarly,
we want to add the capability to blacklist based on the value of a SAML
NameIdentifier. If we assume the NameIdentifier value is a globally unique
string identifier for the authenticated user, a blacklist of name IDs is really
no different than a blacklist of IP addresses.
NameIdentifier formats that qualify for blacklisting include the following:
The first two are defined in SAML V1.1 Core while the latter is defined in the
MACE-Dir SAML Attribute Profiles (see below, respectively).
This thread in gridshib-dev is relevant:
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" ...>
<!-- add the following GridShib config params -->
<parameter name="global-enableBlacklisting" value="true"/>
<parameter name="global-consultDefaultGridmap" value="false"/>
Added the new "blacklistNameIdentifiersFile" config parameter to the
(mis-named) ShibbolethConstants interface:
Added a "blacklistNameIdentifiersFile" config parameter to the 4.0 EchoService:
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
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 :-)
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(?)
(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
(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:
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:
- extends org.globus.gsi.jaas.SimplePrincipal
- (move this class to GS-ST)
- if a SAMLIdentity is trusted, create a SAMLPrincipal
- (push this functionality back into GS-ST)
- 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)
- check IP address
- check all SAMLPrincipals
- check GlobusPrincipal
- 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
This blacklist implementation will be released with GS4GTv0.6.0.