Some thoughts regarding this implementation:

- To build the Subject of the query, use the NameIdentifier element (verbatim)
from authentication assertion, not the Subject element.  The reason is that the
query Subject should not have SubjectConfirmation elements, whereas the Subject
elements of authentication assertions often do.

- If the NameIdentifier/@NameQualifier attribute is missing, use
Assertion/@Issuer.

- If both NameIdentifier/@NameQualifier and Assertion/@Issuer attributes are
missing, fall back on the current method of determining the IdP.

Hope this helps.

Oops, I just checked the spec and discovered that the Assertion/@Issuer
attribute is required.  That simplifies the algorithm somewhat: If the
NameIdentifier/@NameQualifier attribute is missing, use Assertion/@Issuer.
Period.

If the Assertion/@Issuer attribute is missing, the authentication assertion is
not usuable.  In particular, in Phase 2, it will not be possible to check the
issuer against a list of trusted SAML authorities without that attribute.  Thus
a missing Issuer attribute should result in an error.

NameIdentifier/@NameQualifier is the IdP providerid and we use it to find the
AA from the list of AAs, whereas Assertion/@Issuer is a DN, right? I'm not
clear about falling back to Assertion/@Issuer if NameIdentifier/@NameQualifier
is missing. We are comparing NameIdentifier/@NameQualifier and
Assertion/@Issuer in the SAMLAuthnAssertionPIP and issue a warning if there is
a mismatch. This is unclear as well. 

Both NameIdentifier/@NameQualifier and Assertion/@Issuer are providerIds.  Here
is a relevant quote from the Shibboleth protocol spec:

The NameQualifier attribute MAY be omitted if it can be assumed from the
context of the message containing the element (e.g. the issuer of a containing
assertion or the recipient of a query).

Moreover, NameQualifier and Issuer need not be the same.  The NameQualifier is
the IdP that asserted the NameIdentifier whereas the Issuer is the IdP that
issued the assertion.  In today's browser profiles, these two are the same, but
other profiles involving multiple IdPs (such as myVocs) may give rise to
situations where the two are different.

Given this, I think it is reasonable to fall back on the Issuer attribute if
NameQualifier does not exist.

http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-arch-protocols-latest.pdf

ok. sounds good. Another question: I seem to have assumed there can be multiple
authentication statements in an authentication assertion. Does it make sense to
have multiple authentication statments in an authentication assertion? 

 >ok. sounds good. Another question: I seem to have assumed there can be
multiple
 >authentication statements in an authentication assertion. Does it make sense
to
 >have multiple authentication statments in an authentication assertion? 

Multiple attribute statements in an assertion makes sense (I assume your use of
'authentication' in the first sentence of your question was a mistake).

I could envision multiple authentication statements, though we have no
immediate use case. If it's not difficult, I would treat them iteratively
(store all the identifiers and then query the AA's in turn). If it's a problem,
use the first and ignore the rest.

To answer Raj's question (Comment #5), yes, multiple authentication statements
(each with its own Subject element) are allowed but I've never seen a use case
for more than one authn statement in an assertion.  Moreover, in SAML 2.0, an
assertion may have only one Subject element, so anything we do with multiple
subjects in SAML 1.1 will not carry over into SAML 2.0.  Therefore, I would
think that multiple authn statements are a very low priority, and in fact, I
would counsel against doing something in SAML 1.1 that can not be done in SAML
2.0.

To respond to Von's comment (Comment #6), I don't believe we have any code that
processes pushed attribute statements.  Somebody please correct me if I am
wrong.

Shibboleth has been modified to use the Idp ID and Name ID from SAML authn PIP.
Flag added to SAML authn PIP to indicate where to take the authn assertion. I
need to move the code that creates the proxy and puts the authn assertion into
it to the tree. I'm planning to put it in gridshib/proxytools. I did install
shibboleth idp (tomcat only). From the browser,
https://localhost:8443/shibboleth-idp/ gives a directory listing and
https://localhost:8443/shibboleth-idp/AA gives Shibboleth Identity Provider
Failure. When I run the shib-aa-test, "/opt/shibboleth-idp/bin/shib-aa-test -i
https://idp.example.org:8443/shibboleth-idp -p /Users/Raj/.globus/usercert.pem
-q /Users/Raj/.globus/userkey.pem -r /Users/Raj/.globus/simpleCA/cacert.pem", I
got the following error:
** SAML problem:
Invalid credentials for request.

** Solution:
This error means that the SSL handshake worked (that is good), but that the AA
processing has determined that the credentials used are not valid.
This is typically because the credentials presented do not match what the AA's
credential configuration is for the SP providerId you're using.

You need to either:
1) adjust the AA's metadata configuration and add this credential to the SP
providerId's keys section.
2) present a different credential
3) or use a different SP providerId

I tried putting my cert in /opt/shibboleth-idp/etc/example-metadata.xml but it
did not help. Any suggestions? 

Taking the issue in Comment #8 to mailing list gridshib-beta@globus.org

> I'm planning to put it in gridshib/proxytools.

At some point (soon) we'll want to commit the GridShib CA as well, so I wonder
if something a bit more general would be useful.  How 'bout gridshib/x509tools?
 Regardless, this new CVS subtree should be able to accommodate Java, perl, and
maybe even C/C++.  Does this sound reasonable?

(In reply to comment #10)
> > I'm planning to put it in gridshib/proxytools.
> 
> At some point (soon) we'll want to commit the GridShib CA as well, so I wonder
> if something a bit more general would be useful.  How 'bout gridshib/x509tools?
>  Regardless, this new CVS subtree should be able to accommodate Java, perl, and
> maybe even C/C++.  Does this sound reasonable?
> 
Yes. I changed it to gridshib/x509tools

I committed the changes to cvs. I did some tests. chooseAA and subject building
seems to be fine. I'm having some problems getting the echoservice test to work
(posted it on gridshib-beta) so i couldn't test this fully yet.

The last comment (Comment #12) reported a problem with testing.  Can you say
briefly how you solved this problem and also provide some links to online
resources now available as a result of your overall work?  Thanks.

The problem I mentioned with echoservice was mainly because the
globus-container was using a proxy certificate and the tomcat could not
recognize it. Running the container with EEC (containercert.pem) solved this
issue. This feature is available in the technology preview of GridShib for GT
v0.4.1 
http://gridshib.globus.org/downloads/gridshib-gt-source-0_4_1-tp1.tar.gz
Information on how to install and configure this technology preview is
available at 
http://gridshib.globus.org/docs/gridshib-gt-0.4.1-tp1/install.html