Shibboleth Developers

["Scott Cantor" <>]

> First of all thanks for RC1. So far it seems to run pretty smooth and
> seamless :)

Thank you for testing. Unfortunately there's a deadlock in the metadata
chaining code when duplicates are involved, but it's been fixed.

> So, are the RC1 configuration files now as they will be for 2.0 final?

No, they will probably change a little, but the schema won't. Whatever is
compatible with RC1 will be compatible with the final version.

> If so, does anything speak against setting the signing attribute to true
in:
> 
> <Handler type="MetadataGenerator" Location="/Metadata" signing="true"/>
> for the distrubtion shibboleth2.xml?

Well, that doesn't distribute shibboleth2.xml, it generates sample metadata
which is at best a guess. It's not intended for real time use, and I don't
think it will work well for that.

Also, if you have an open endpoint that causes a digital signature, it's
trivial to bring down your server. Same problem with signing an
AuthnRequest.
 
> This could be useful in our case
> when we want to verify the possession of an SPs private key before we
> let somebody embed e.g. a self-signed certificate.

Unless you can prove when they signed it, I don't think you have a workable
model.

> Other question: Is the attribute resolver feature already included in
> RC1? If so, how can it be used? I have only found information concerning
> odbc store but not for attributes

The resolver plugin provided does SAML queries for compatibility with 1.x.
Attributes themselves are stored along with the session in the same place as
everything else is.

If you want support for local resolution of LDAP or database attributes, I
don't have a plugin for that, only an API that will eventually be
documented, although there are javadoc-style docs already for every public
API in the system.

-- Scott