Implemented class org.teragrid.ncsa.gridshib.security.util.SAMLUtil with the
required static method.  Implemented a corresponding unit test.

Committed all resources to CVS HEAD.  This new feature will be distributed with
the next release of GridShib SAML Tools (or the next release of GridShib for GT
depending on the resolution of Bug 6426).

New resources:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/teragrid/java/src/org/teragrid/ncsa/gridshib/security/util/SAMLUtil.java?view=log
http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/teragrid/java/tests/org/teragrid/ncsa/gridshib/security/util/SAMLUtilTest.java?view=log
http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/teragrid/java/tests/org/teragrid/ncsa/gridshib/security/GatewaySecurityContext.java?view=log

Reopening this bug.  Adding gram-dev to the cc list since GRAM depends on this
class.

The SAMLUtil class defines a getGatewayIdentity method that retrieves the
gateway user identifier from the security context:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/teragrid/java/src/org/teragrid/ncsa/gridshib/security/util/SAMLUtil.java?view=log

The current version of the getGatewayIdentity method identifies a potential
gateway user by examining a prefix of the corresponding SAML issuer (i.e., the
entityID).  Since the prefix is hardcoded into the SAMLUtil class, this method
is brittle.

Actually, this method of determining the gateway user is a bug.  Suppose an RP
mistakenly configures metadata containing an entityID such that a prefix of the
entityID matches the prefix hardcoded in the SAMLUtil class.  Then the SAML
issuer corresponding to this entityID can impersonate a Science Gateway.  This
may result in an incorrect access control decision.  In the very least, it will
result in a bogus gateway user identifier appearing in the GRAM audit DB and
subsequently in the TGCDB.

(In reply to comment #4)
> 
> Actually, this method of determining the gateway user is a bug.

The solution to this problem is to implement a PIP in GS4GT that computes the
gateway user identifier *and then stores the identifier in the user's security
context* (Bug 6652).  The getGatewayIdentity method in the SAMLUtil class can
retrieve the identifier from the security context.  (I'm not sure why I didn't
think of this before.)

To this end, we define a TGSecurityContext interface with a
getTeraGridPrincipal method:

public interface TGSecurityContext extends SecurityContext {
    public TeraGridPrincipal getTeraGridPrincipal();
}

We provide an implementation of the TeraGridPrincipal class as well.  The
SAMLUtil class can use these components to implement the getGatewayIdentity
method.

Removed these constants from the SAMLUtil class:

final public static String ENTITYID_PREFIX =
    "https://saml.teragrid.org/gateway";

final public static String TGPN =
    "http://teragrid.org/names/nameid-format/principalname";

TGPN is no longer needed since it is now part of the Globus SAML Library (Bug
6679). ENTITYID_PREFIX is involved in the buggy computation described in
Comment #4, so it definitely has to go :-)

Completely refactored the getGatewayIdentity method in the SAMLUtil class.  The
method relies on the TGSecurityContext interface and the TeraGridPrincipal
class described in Comment #5.

Changed the visibility of some members of the SAMLPrincipal class to
accommodate the TeraGridPrincipal class (which is a subclass).

Implemented a new getTeraGridPrincipal method in the GatewaySecurityContext
class (which is a helper class for the SAMLUtil unit test).  The
GatewaySecurityContext class is essentially a proof of concept for the eventual
implementation of the TGSecurityContext interface.

Committed all resources to CVS HEAD.  This patch will distributed with GS-ST
v0.5.4, which unfortunately is not bundled with Capability Kit V2.  Keeping
this bug open until we figure out how to distribute this patch.

(In reply to comment #10)
> This patch will distributed with GS-ST
> v0.5.4, which unfortunately is not bundled with Capability Kit V2.  Keeping
> this bug open until we figure out how to distribute this patch.

It was a mistake to reopen this bug (which blocks Capability Kit V2).  Instead,
a new bug should be opened for this work.  All of the content of Comment #4,
Comment #5, Comment #6, Comment #7, Comment #8, Comment #9, and Comment #10 has
been moved to Bug 6683.

This bug is now closed (and it should not be reopened).