Shibboleth Developers

[Nate Klingenstein <>]

I'm not going to be available for this call, so here is a brief  
textual update on my two items listed below:

>         -- summary, look at Idaho Java SP (Nate)

I grabbed a copy of the JBoss-SAML implementation that was contributed  
by Nick Newman from Idaho National Labs and brought it up and  
running.  The process would have been quite fast and painless were it  
not for several beta-ish hitches I uncovered during the testing  
process, including:

• The patch doesn't apply against versions of JBoss other than 6.0.0.M2
• The Setup.sh script didn't work, though invoking Setup directly  
through java did
• There are a lot of path-related issues, where the location from  
which a script is invoked will affect the locations where files
• Some warnings are extraneous

Some of the more potentially significant issues:

• 00:34:58,014 WARN  [gov.inl.jboss.saml2.SAMLv2Authenticator] A SAML  
ticket was found to be invalid.  The message from the exception is:  
The current time Thu Oct 14 00:34:58 EDT 2010 is before the NotBefore  
time Thu Oct 14 00:35:30 EDT 2010 in the Conditions by more than the  
allowed skew of 5000 milliseconds

5000 milliseconds of skew seems to be quite tight, though I have to  
confess that I don't know Shibboleth's default here off-hand.

• Support for the POST SSO AuthnRequest profile might be limited in  
some deployments.  For example, simpleSAMLphp, which is fairly widely  
deployed, doesn't support it.

• The Subject is made REMOTE_USER.  While that's appropriate with some  
IdP's, it will almost never be appropriate with Shibboleth, where the  
subject is a transient ID. It'd be nice to be able to map an attribute  
to REMOTE_USER.

And feature requests:

• The biggest feature request I'd have is the ability to load metadata  
from a file with many entities, as that will be most federations  
nowadays.  It'd also be way cool to have DS support so that developers  
can take advantage of the new embedded WAYF.

• Default mappings for common attributes would be neat to add if they  
don't introduce too much overhead from having extraneous environment  
variables populated. Double brownie points if they use the same  
default variable names as the Shibboleth 2.0 SP.

It's most definitely usable in its current state, particularly for  
deployments involving one IdP, but as the list above indicates,  
there's probably some more effort required to get the software to a  
point where it could drop into many federated deployments comfortably.

>         -- TestShib and ICAM testing (Nate)

John Bradley has asked me to examine the possibility of using TestShib  
as SAML test endpoints for the ICAM SAML profile.  There's a handful  
of requirements that he'd like to put into the interop testing that  
Shibboleth proper can't support right now.  As such, I'm going to be  
cobbling together over the next week or two a separate testing  
facility on TestShib.  It will consist of some horrific chimaera of  
software components that ought to suffice for most of the conditions  
we'd like to have in place.

For everything else, there's assertions dumped into log files.