Shibboleth Developers

1) if an IdP relyingparty config, profile element contains 
encryptAssertions="true", but SPSSO element in metadata only has a 
key with <md:KeyDescriptor use="signing">. the IdP produces a msg 
with:

Unable to construct encrypter
Key encryption credential may not be null

Chad asked me to submit this; msg not very descriptive.

2) IdP resolver configured to use ldap; logged in with a uid that's 
not present in ldap. Got NullPointerException.

log file available at http://stc-test11.cis.brown.edu/idp-process.log-stc1

go to line 4547.

all of the remaining points use the log file at 
http://stc-test11.cis.brown.edu/idp-process.log-stc2

Note -- this log file contains multiple SAML transactions..... and 
the config files were changed between some of them.

2) SSO transaction starts at line 4317; question relates to line 
4581. (Note -- at this point, I was using the default filter 
policies, so only transientId is being released.)

The IdP is encoding attributes at this point; this msg appears:

Attribute transientId was not encoded because no 
SAML2AttributeEncoder was attached to it.

shouldn't the distributed config files contain the appropriate 
element, so this succeeds?

3) line 4673; this line appears:

> Unable to determine length in bits of specified Key instance

should I be concerned?  ;-)

4) the previous 2 points referenced an SSO processing; all attributes 
were filtered out, so an Attribute Query begins on line 4713.

The IdP seems to be trying to identify who is referenced by the 
query. On line 4873, I see this msg:

> Using principal connector saml1Transient to resolve principal name.

the only thing that concerns me is the saml1Transient word -- since, 
based on the previous contents of the log, I'm pretty sure that the 
IdP sent a saml2format identifier... ?

5) line 4975 once again sees (point 2, above)

> Attribute transientId was not encoded because no 
> SAML2AttributeEncoder was attached to it.

6) line 4981, 3 contains:

> Supported NameID formats: [urn:mace:shibboleth:1.0:nameIdentifier]

> No principal attribute supported encoding into a supported name ID format.

which seems odd, since it did find an appropriate format during the 
SSO stage....

7) If you're interested, another new SSO transaction starts at line 9997.

around line 10,259 you can now see 3 attributes being filtered 
successfully, and then encrypted....