Skip to Content.
Sympa Menu

shibboleth-dev - RE: Second and final beta of 2.0 SP available

Subject: Shibboleth Developers

List archive

RE: Second and final beta of 2.0 SP available


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Second and final beta of 2.0 SP available
  • Date: Tue, 15 Jan 2008 12:05:49 -0500
  • Organization: The Ohio State University

> Yes - that was what I thought you meant, but it was such a surprising
> feature that I thought I had best double check!

It's always been there, but I think I botched the libcurl settings up until
1.3.1. It's generally there only for interop with SAML products with botched
TLS support but that do use basic-auth.

I would note that the SP at the moment does not have any support for using
anything but TLS or message signatures on *incoming* SOAP messages. It's not
impossible to do it, but the demand isn't really there to implement it.

> (FWIW there was a bug in libcurl that tripped me up (some time ago) that
> required a username (anything) to be set before it would do anything
> with GSS. It didn't use the username for anything,it just insisted on a
> value. I have no idea if this has been fixed)

I don't think so, I saw it in the docs. But I can mock up the username for
that setting, rather than require a name/password be supplied in the config
file.

> The addition of GSS is really interesting. You could do some crazy
> things with this.

I suspect so, I'm leaving it to other people to figure out what those might
be. My "real" Kerberos realm is completely untouchable (I can't create
service principals and such) so it's worthless to me and impossible to use
to explore these kinds of features.

> Does the IdP do any of this (ie. using the Java binding to libcurl, or
> does it use JAAS)? I'm still trying to understand the new architecture,
> although the new docs for Shib 2.0 are *very* good.

They're improving, that's about all I'll say for now. It's incredibly time
consuming, for me anyway.

The IdP to my knowledge does not support anything but TLS and message
signing for incoming SOAP. Architecturally, again, it should be able to
support other things, probably by leveraging REMOTE_USER and implementing
whatever the feature is inside the web server or container. But mapping from
REMOTE_USER to an actual entityID is the tricky (and unscalable) bit. That's
why I tabled it for the SP.

Ironically, it would work much more directly to have users with a SOAP
client authenticating with their password.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page