Shibboleth Developers

[Scott Cantor <>]

> Looks like you're saying look outside Shib proper for the tools to roll 
> this kind of app, or wait for Shib/Lib/SAML convergence.

Yeah, I guess. But let's say I needed this functionality today and I didn't
want to make code changes to Shib.

The origin side is simple, it amounts to deploying a second HS with a
properties file specifying the higher end auth method, and then protect it
with my higher end authentication.

Now I either set up a special WAYF that treats the two different methods as
a distinct origin site (even if they aren't really different), or I setup my
target to use vhosts that go directly to one HS or the other.

And I would, in keeping with my usual approach, do nothing at the
application level to make it happen. I'd move the scripts that were subject
to this higher requirement to /secure/medapp or a different vhost and let my
web server configuration do the work. Such is the magic of URLs.

I simply check the auth method header Shib provides me and I know which
policy was used.

This will be much easier when it's part of the protocol, but web servers can
do a lot of this for me today.

Lastly, I'd always warn anyone doing this that I would never attack your
authentication system to crack your medical application. I'd attack your
application's session cookie. As long as the client is a browser, there's
not all that much you can do except to use client certs and check the cert
on every request.

I think a really interesting question is why this authentication context
stuff is so superficially appealing to people. I must be missing something.
;-)

-- Scott