Shibboleth Developers

["Scott Cantor" <>]

> I'm not sure I entirely understand.  Would it help if there were a
> tool that produced metadata from the underlying config?

That's the step you do after you know what the configuration is. The
simplest piece of information I'm talking about is the hostname, but you can
add the providerId to that, and numerous other things, not to mention
generating the key and cert.  This of course doesn't include any Tomcat
issues that might need addressing.

> Ah, I see, then maybe you should rewrite that line in the Roadmap
> since it seems to imply you're gonna support the SAML 2.0 IdP
> Discovery Profile.

It just says cookie, I think, but it's not precise enough anyway.

> Again, I think you're focusing on the SSO profiles.  I have a use case
> today that could leverage signed attribute assertions.  They would
> save us a ton of work.

The Shib SP only does SSO. The feature you're describing requires a context
and the SP context is a web server. The feature is "expose signed security
assertions for the session to web applications running behind it" for use
with additional profiles.

I could be wrong, but I don't see how that addresses anything you're
probably thinking of. It's orthogonal, essentially. If you're doing
attribute queries yourself, then you get the result back yourself. You may
be reusing SP code, and heck, maybe even part of the configuration, but it's
still a separate thing and it can do whatever you need it to do.

The C++ SP libraries are *already* modular enough to support a stand-alone
query agent. I know because I built one using them, way back in the 1.1
days. It's a safe bet the Java version of those libraries will be at least
that usable.

It's really a much simpler problem than what the actual SP has to do.

-- Scott