Shibboleth Developers

["Scott Cantor" <>]

> I assume you mean the Shib 2.0 IdP will interoperate with all SPs
> (except 1.1), but that the Shib 2.0 SP will only interoperate with the
> Shib 2.0 IdP.  Will the Shib 2.0 SP consume SAML 1.1 assertions?

No, we don't mean that. Both ends will be multi-protocol aware. Though I
assume we'll follow through and break interop with the 1.1 IdPisms just like
we're doing the opposite way.

The presumption is that the SP will have protocol handlers for SAML 1.0,
1.1, 2.0, and ADFS initially. Which bindings and protocols depends on demand
and time.

> > Identity Provider
> > Enhanced installation, deployment, and manageablity features:
> 
> FWIW, I agree with Jim on this point: Shib 2.0 should "just work" out
> of the box, which necessitates a bilateral deployment.

It can't do this unless we ask for all the information needed to fill in all
of the options we need to set for the installation. We can probably fudge
the login issue by delivering a config that uses a Tomcat user realm file
for login, whatever the use of that.

> Awesome!  If the Java SP can consume SAML 1.1 assertions, we will
> almost certainly find use for it in our project.

It should support whatever the standard SP supports.

> >     * Support for SAML IdP cookies as defined by the SAML 2.0
> >     specification
> 
> Maybe I'm missing something but I don't see the utility of this
> profile.  In any event, can/should this be pushed back to Shib 2.1?

The SP already supports this, sort of. There isn't much else to do. This
isn't the shared domain thing, so the IdP doesn't really get involved.

> - A robust mechanism at the SP that exposes a signed attribute
> assertion to applications

This is pretty much a must have for 2.1, but it probably will get done for
2.0. To a point anyway, but the whole approach is really geared to 2.0
assertions. There's nothing really useful about having a signed 1.1 SSO
assertion or attribute query results as they are not forwardable. At least
not in the context of what the SP's doing. Obviously raw SAML code using the
same bits to do something new is free to do whatever it likes.

> - Support for AuthnRequest/@IsPassive [Shib 2.1 feature?]

Chad addressed this, I think, anything that's essential to core 2.0 SSO is a
2.0 deliverable.

> - Support for LOA attributes

Not sure what you mean precisely. There's going to be something with
AuthnContext...

-- Scott