Shibboleth Developers

["Scott Cantor" <>]

Here's some sketchy thoughts on generalizing the SP configuration for 1.3
and beyond. The goals here are to put things in place for SAML 2.0 support
while dealing with the addition of artifact, e-authn, and possibly other
WAYF models like the domain cookie and so forth.

I think the most efficient processing model is going to be to split up
profiles and bindings on separate endpoints but give them a common root URL
and use Path Info to distinguish them (e.g. /Shibboleth.sso/SAML/POST)

Otherwise it's too intensive for me to figure out whether an incoming
request is just for a resource or if a protocol handler has to step in.
Without that ability, it's harder for simple deployments to just protect an
entire web site, and we have a lot of that here.

But I don't think this is a problem. Nobody cares what the "SHIRE" URL looks
like now, and metadata requires that each binding/profile have its own
element anyway, even if the location happens to be the same.

The old (allowed but deprecated) syntax:

<Sessions lifetime="7200" timeout="3600" checkAddress="true"
        wayfURL="https://wayf.internet2.edu/InQueue/WAYF";
        shireURL="/Shibboleth.shire" shireSSL="true"/>

New extended (yes, more complex) syntax:

<Sessions lifetime="7200" timeout="3600" checkAddress="true"
        handlerURL="/Shibboleth.sso" handlerSSL="true">

        <SessionInitiation Location="/WAYF/InQueue"
            wayfURL="https://wayf.internet2.edu/InQueue/WAYF";
            wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>

        <md:AssertionConsumerService Location="/SAML/POST"
                Binding="...1.1 POST profile URI"
                isDefault="true" index="1"/>

        <md:AssertionConsumerService Location="/SAML/Artifact"
                Binding="...1.1 artifact profile URI"
                index="2"/>

        <md:AssertionConsumerService Location="/EAUTH"
                Binding="depends how close they end up to real SAML ;-)"
                index="3"/>

        <md:SingleLogoutService Location="/Logout"
                Binding="urn:mace:shibboleth:sp:1.3:logout"/>

</Sessions>

Notes...

I figure ".sso" is as unlikely to collide as ".shire" but could be wrong,
doesn't matter what gets used. The point is just to quickly derive the
https://host/Shibboleth.sso URL and then strstr() that with the target URL
like now, and then if it hits, the Apache/IIS/NSAPI handler will examine the
Path Info and use the config elements to figure out what to do.

I went ahead and used the SAML metadata schema for the two overlapping
elements. I went back and forth, but in the end I found a use for the
default and index ACS bits in the new lazy session function, so I figured
I'd just import it.

Each profile/binding will have its own sub-handler location, so it will be
faster to figure out how to proceed (or fail) and less error prone for
testing IMHO.

The Logout element is of course mainly for 2.0, but I figured I'd just add a
cookie clearing option now. It's not single logout, there's no IdP
involvement, just give it a return location and it will clear the session
and redirect back. If people want to build hacks on top of that, whatever,
I'm just preparing for 2.0 or whatever we do between now and then.

The SessionInitiation thing is mainly to separate the lazy session builder
endpoint from the rest of the handlers, and I figured I'd build in support
now for invoking different WAYFs with different request profiles. The lazy
session mechanism will be extended somewhat, like a providerId parameter to
specify an IdP to use and an acsIndex to specify the return point/profile
(also needed later for 2.0).

Somewhere in that mix would be in internal metadata-driven mini-WAYF and the
common domain cookie stuff, but not much thinking on that yet, per my other
note.

I'm not wedded to any of this, but objections need to be voiced fairly fast
as I have a lot of coding to do.

-- Scott