Shibboleth Developers

["Scott Cantor" <>]

A bit more progress, and some thoughts on the Handler stuff.

The latest Unix defaults look like this:

http://svn.middleware.georgetown.edu/view/cpp-sp/branches/REL_2/configs/shib
boleth2.xml?revision=3283&view=markup

There's nothing between the top and the ApplicationDefaults section, the
TrustEngines are defaulted, and a lot of rarely or unused settings are
pulled/defaulted to reduce attribute clutter.

The big piece left is the Sessions children, and I think I have a proposal
for that. Originally I was thinking I'd try and wrap that in some new plugin
API so that it would be easier to adjust later, and could be moved to a
separate file, but I really think having it separate will be more confusing,
so I'm instead looking at trying to add an alternate syntax that's as
concise as possible.

There are basically two ways to express the information about protocols:

- combine protocols up into functional elements (<SSO>, <Logout>)
- combine functions into protocol elements (<Protocol type="SAML2">)

It turns out that the latter, while having some advantages, makes
constructing the SessionInitiator chain (which is the stuff that actually
changes) really difficult, particularly when discovery is involved.

The former creates some potential for conflict between plugins of a given
type sharing the same properties, but in practice that rarely causes
trouble, and in fact the whole point of inheriting settings from the
Chaining SessionInitiator is to avoid duplicating them on each element
anyway. And the old syntax isn't going away, so if there's a problem with
the new syntax, the old one can be used when necessary.

So the idea I had was roughly this:

<Sessions... as now>

        <SSO entityID="..." relayState="...">SAML2 Shib1</SSO>
        <Logout relayState="...">SAML2 Local</Logout>

        <!-- custom stuff as now -->
        <Handler ...>
        <Handler ...>
        <Handler ...>
</Sessions>

(If you want logout, you have the <Logout> element, if not, it's just
removed. Same for the NameIDMgmt stuff, and that of course won't be in the
default file anymore.)

I should be able to auto-generate the necessary handlers based on this,
while still allowing a choice of protocols.

If you have discovery instead of a single IdP, the SSO would be:

<SSO relayState="..." discoveryProtocol="SAMLDS" discoveryURL="...">
SAML2 Shib1
</SSO>

There are lots of additional properties still usable to override settings,
customize bindings, that kind of thing, but the 90/10 case will probably
just look like these.

The values inside the SSO and Logout elements are, naturally, the plugin
types for the Session/LogoutInitiators now, which isn't terribly awkward
given what I named them. This will still allow for extensions (e.g. ADFS
should still work, by adding that in).

Still some detais to work out, plus actually seeing if it works, but that's
what I'm thinking.

-- Scott