Skip to Content.
Sympa Menu

shibboleth-dev - RE: passive authN

Subject: Shibboleth Developers

List archive

RE: passive authN


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: passive authN
  • Date: Wed, 2 Nov 2005 16:40:32 -0500
  • Organization: The Ohio State University

> Collecting credentials is indeed the tripwire for me. The AuthN Req/Resp
> stuff seems focused on authN metadata and doesn't oblige the IdP to
> handle actual creds.

Only insofar as the thing that does handle actual creds is able to adhere to
its obligations. That means it's either SAML-aware (i.e. it examines the
AuthnRequest) or is something new we have to define.

In either of those cases, not supplying Java implementations of the
functionality that 99% of the downloaders would need to deploy a working IdP
is just not right. I would argue it wasn't right before, in fact, but I
didn't have as strong of a technical case. I think most of the community
would agree with me, large R1 institutions notwithstanding.

> Agreed, so I think a discussion should occur in which that boundary is
> scouted. It *might* be reasonable to specify a means to enable a
> conforming SSO to integrate with a SAML2 IdP, or at least a shib 2.0 IdP.

It might, but it always struck me that defining something that would require
other codebases to change internally wasn't really all that useful over and
above each of them simply implementing a few lines of Java code that would
be entirely separate. And that's for the ones that can...if your SSO system
doesn't support some of the features, it simply may not even work right.

The other piece is where to do the "profiling" of the AuthnContext that a
given handler supplies, and I think the IdP config is the right place to do
that. If you want to multiplex different authn methods within a single
handler, you're free to do that, or tell the IdP explicitly to dispatch to
different places for different methods.

Basically, while being sensitive to owning too much of the terrain, this is
fundamental terrain for Shibboleth. Allowing a separation and doing a lot of
extra work to allow it are very different propositions, and we have a lot to
do already. Of course, if a community springs up that wants to own that
problem...

I guess to be pragmatic, there's a lot of stuff in Shibboleth because I
really, really needed it. In some cases I did the work to make it happen,
and in others, I leeched off Walter. ;-) But this one isn't important to me
at all, so let's find some volunteers. I guess you and Jim are first up?

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page