Skip to Content.
Sympa Menu

shibboleth-dev - RE: Enhanced WAYF

Subject: Shibboleth Developers

List archive

RE: Enhanced WAYF


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: "'Shibboleth Development'" <>
  • Subject: RE: Enhanced WAYF
  • Date: Mon, 15 Nov 2004 21:15:58 -0500
  • Organization: The Ohio State University

> And that someone is me...I think I have it backwards, requests to the
> subdirectories can see _shib_idp_history but not vice versa. Oh well,
> back to the drawing board...

Right, I thought so. After your last note, I was headed for my own drawing
board. ;-)

Anyway, my main concern is that there really isn't a great way to "append"
SP identifiers (which are typically URIs) to a URL as path-info. It's
possible, sure, with some kind of transformation, but I think it's simpler
just to use what we have, which has the added advantage that it's fully
compatible with 1.2.x. It's even possible to just redirect the browser from
there into a per-SP path managed by the WAYF if you want to, but the SP
remains oblivious.

If you want to set a second per-SP cookie on the /WAYF servlet path, I think
that's fine. It will work exactly as you intend, and if you want to "favor"
that value over the global history list, that's fine too, since it's
internal to the WAYF what you return when an SP sends a cookie read request.

All the GUI/UI ideas you presented are basically fine (and more or less
similar to what we've discussed in the past). The reason we haven't done it
is not that it's hard, but that it's easy. We just haven't found the time to
bother with the WAYF much when we're busy doing SAML stuff.

But, I *think* what you proposed (once we decide some unimportant details
like whether to return the whole history list on a read) is completely
within the scope of an implementation of the current spec on the table.
Which is good, because it means we probably are close to a minimal solution,
which is what the spec is aiming for.

I think it would be a better exercise to test that assumption than to
proceed by writing more specs.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page