Shibboleth Developers

["Scott Cantor" <>]

> Is the new SessionInitiator functionality of the SP documented anywhere 
> yet?

No, I have it on my TODO list as one of the main new features that would be
impossible to figure out from the comments.

> If not - do I understand correctly that this should allow runtime 
> determination (via lazy sessions, etc) of which WAYF or direct IdP the 
> user goes off to to establish their session?

Yeah, it's hard to pin down exactly what you can and can't do without
specifics, but basically the process of handing the user off for a lazy
session request is cleaner, and supports multiple lazy request handlers, and
potentially uses metadata to locate the IdP's SSO service and even
potentially what protocol to use (Shib now, SAML 2/WSFed later, etc).

It's not quite a WAYF yet, exactly, but it's intended to be a starting step
toward bundling something like that, or at least making the SP's job easier
since it doesn't have to actually build the Shib requests or figure out
where the SSO service is.

> Could someone supply a 
> quick usage example (query parameter string, e tc)?  Between the 
> shibboleth.xml embedded comments and looking at the code, I 
> don't think I understand exactly how it's supposed to work.

Heh, it's in the code! Seriously, I have a comment in there:

         * Binding is CGI query string with:
         *  target      the resource to direct back to later
         *  acsIndex    optional index of an ACS to use on the way back in
         *  providerId  optional direct invocation of a specific IdP

I defined a Binding value of urn:mace:shibboleth:sp:1.3:SessionInit to stand
for "the Shib 1.3 lazy session handler protocol". I just made it up, so that
in theory other ways of doing this could be plugged in and identified. The
whole handler subsystem is pluggable now, but that's off-topic.

Anyway, so the query string protocol is "invoke the SessionInitiator
endpoint with at least one parameter (target, like now) and optionally two
other parameters, listed above. One of them can tell the handler what IdP to
use by name and the other can tell it which incoming handler to come back to
(what to put in the shire parameter, basically).

> How does one explicitly invoke a specific initiator (other than the 
> default), for example with a lazy session?  

See above. You redirect to the handler you want to use with at least a
target parameter, and optionally the others.

> requestSessionWith?

This isn't for lazy sessions, it's for telling the software instead of just
to require a session that it should get the new session by using the named
initiator. Each initiator can have its own wayfURL. So technically what it
does is allow the SP to figure out up front via a URL trick or something
which WAYF to use and then you can use requireSessionWith to get to the one
you want. It's to avoid needing multiple applications just to have multiple
WAYFs configured. Whether it's useful I dunno, but it fell out of the design
without doing a lot of work.

With lazy sessions, the application decides when to initiate, so it can
select the handler to use at runtime based on where it sends the redirect.
And each handler has a wayfURL, so you can name/locate the handlers
something reasonable, as I did in the sample.

> Does it make a difference whether sessions are lazy or not?   I tried
playing
> around with it, but I keep getting an error that I need a wayfURL property
> (which I have),  so I'm obviously doing something wrong...

I'm not sure what you're doing. Any Shib SessionInitiator element has to
have a wayfURL in it so that if you don't send a providerId it knows what to
do. That doesn't have to point at an actual WAYF, but I kept the attribute
name the same.

> Finally, what is the purpose/meaning of the SessionInitiator Location 
> attribute?  That's not obvious to me.

The default configuration right now:

Base handlerURL
        /Shibboleth.sso

Endpoint locations:
        /SAML/POST
        /SAML/Artifact
        /WAYF/InQueue
        /WAYF/idp.example.org
        /Logout

So how do you accept a posted assertion? Post it to
https://hostname/Shibboleth.sso/SAML/POST

Artifact? https://hostname/Shibboleth.sso/SAML/Artifact?<parameters>

Initiate a session using the InQueue WAYF?
https://hostname/Shibboleth.sso/WAYF/InQueue?target=yaddayadda

Make sense?

-- Scott